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

[wren ng thornton]

On 5/8/12 3:56 AM, Ivan Tomac wrote:
> 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.

Sure. I was just pointing out the paranoia option ;)


>> 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.

I was meaning more that some folks might be concerned about the slowdown 
compared to the current implementation. Which we should really quantify 
before replacing the old implementation. If it's significant, I'm fine 
with having different implementations based on whether you're 
performance crazy vs need those features.

> 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?

Sounds like a good plan. Let me know if you want any help with the 
bounded and closeable variants, or with benchmarking.

-- 
Live well,
~wren