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

[Ivan Tomac]

Hi Wren,

wren ng thornton<wren at freegeek.org>  wrote:
> I'm sure reads and writes are atomic (for safety reasons), though I
> don't know if that's formally specified anywhere. It should be though.
>
> If you're paranoid, you can always use atomicModifyIORef which
> guarantees atomicity. Albeit, that's more powerful (and hence slower)
> than you need for plain reads and writes.

I'd rather not use atomicModifyIORef - if IORef reads and writes
aren't atomic I could just use MVars. If IORefs are atomic though, I
would think that it's better to only use MVars where a lock would be
required and use IORefs otherwise.
It seems to me MVars have a fair bit of overhead over plain IORefs.

> If you do break off a separate library (or resolve the bugs to
> everyone's satisfaction), to the extent possible it'd be nice to see
> non-STM versions of stm-chans[1] provided. I'd be willing to help out
> with that over the summer, though it certainly won't make it into this
> month's HP.

Thanks. I have already, as far as I can tell, fixed the bugs,
hopefully without introducing any new ones.
The code is attached to the original post:
http://www.haskell.org/pipermail/libraries/2012-May/017782.html
It's possible it got stripped from the post by the mail client though?
Alright, so perhaps the way forward is to create a new library on
Hackage, and (eventually) remove concurrent channels from base?

Ivan