[stm] strange behavior with TQueue and STM's alternative instance

Patrick Palka patrick at parcs.ath.cx
Sun Dec 9 16:48:34 CET 2012


I'm getting strange behavior when using the 'many' combinator to read zero
or more items off of a TQueue with readTQueue. The script that exhibits
this behavior is as follows:

import Control.Concurrent.STM
import Control.Concurrent
import Control.Monad
import Control.Applicative
main = do
    q <- newTQueueIO
    atomically $ writeTQueue q True
    atomically $ writeTQueue q False
    forever $ do
        xs <- atomically $ many $ readTQueue q
        print xs
        threadDelay 500000

I'd expect the output of the script to be:

However, that is not the case: the actual output of the script is:

This means that TQueue is incompatible with TChan, since if TQueue is
replaced by TChan then the script behaves as one would expect.

If 1 element (say, True) is written into the TQueue instead of 2, then the
output of the script is:

Which is expected behavior, but inconsistent with the behavior when the
TQueue has 2 or more elements in it.

Is this considered a bug, or undocumented behavior of TQueue?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20121209/26c61e6e/attachment.htm>

More information about the Libraries mailing list