Meurig Sage <[EMAIL PROTECTED]> reports:
> There seems to be a bug in the Channel module from
> ghc-0.29.
>
> If I understand the description in the paper
> correctly, dupChan should allow two readers to
> both read all the data passed along a channel.
> This doesn't work because of the way the getChan
> function is written.
>
> It takes the next value from the read end hole, but
> does not put it back into the MVar to allow any other
> reader to access it.
>
> The fix just requires one line:
>
> getChan :: Chan a -> IO a
> getChan (Chan read write)
> = takeMVar read >>= \ rend ->
> takeMVar rend >>= \ res@(ChItem val new_rend) ->
> ***putMVar rend res >>
> putMVar read new_rend >>
> return val
>
Thanks for the report (and fix). (sigh) Yes, there's no reason why
getChan should leave the elements in the Channel stream locked.
Indeed, it is just the Wrong Thing to do when adding dupChan to
the Channel interface. Fixed in the next release; for now, you'll
have to live with your own private copies of Channel, I'm afraid.
--Sigbjorn
[Entry added to bugs page
http://www.dcs.gla.ac.uk/fp/software/ghc/ghc-bugs.html
]
