Proposal: To add 2 new lower-level concurrency constructs and rebuild Concurrent.Chan using them

[Ivan Tomac]

Hi,

I've recently noticed unGetChan and isEmptyChan have been deprecated
as a result of these two bug reports:
http://hackage.haskell.org/trac/ghc/ticket/3527
http://hackage.haskell.org/trac/ghc/ticket/4154

I was working on an alternative implementation of concurrent channels
(concurrent streams) to use as a building block for FRP and thought
while I'm at it I'd have a go at fixing the problem with concurrent
channels.

I've attached the files for a reimplementation of concurrent channels,
2 implementations of lower-level concurrent queues, one that only
supports non-blocking reads, and another that supports both blocking
and non-blocking reads, and an implementation of concurrent streams.

The reimplementation of concurrent channels is built on top of the
blocking queue.
The streams are built on top of the non-blocking queue and have
Functor and Applicative instances.

The reimplementation of concurrent channels passes the two tests in
the bug reports above. I haven't run further tests though. The logic
for how the channel operations are supposed to proceed is summarized
in Chan.hs.
Due to an extra lock this implementation is likely a bit slower than
the old implementation.

One assumption that has been made is that IORef reads and writes are
atomic. In other words that if there are two or more concurrent writes
to the same IORef, one of them will successfully write its data to it.
I have not been able to find exact semantics of IORefs though I've
asked in #haskell and others have suggested that the assumption is
valid.

Proposal:
1) split concurrent channels from base into a separate library of
higher level concurrency primitives
2) add concurrent queues to the library of higher level concurrency primitives
3) replace concurrent channels with the new implementation based on
concurrent queues
4) add concurrent streams to the library of higher level concurrency primitives

I was in a bit of a rush to write this up and post the code after
finding out that the new Haskell platform will be released this month
though it seems unlikely this would go in at this point - probably for
the best as the code hasn't been tested much.
I'm also not sure if concurrent streams would be more appropriate on Hackage?
Thoughts and comments appreciated.

Deadline: 8th of June.

Ivan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Chan.hs
Type: application/octet-stream
Size: 4165 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/libraries/attachments/20120508/cac79413/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Stream.hs
Type: application/octet-stream
Size: 4606 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/libraries/attachments/20120508/cac79413/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Blocking.hs
Type: application/octet-stream
Size: 2832 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/libraries/attachments/20120508/cac79413/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Nonblocking.hs
Type: application/octet-stream
Size: 2281 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/libraries/attachments/20120508/cac79413/attachment-0003.obj>