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

[Simon Marlow]

On 07/05/2012 22:11, Ivan Tomac wrote:
> Just had a few hours of sleep and think perhaps I sent that email out
> too soon. I forgot what my original intention was and just ended up
> submitting a proposal.
>
> The original question I had was what would be the best way to proceed
> with something like this? Have it submitted as a patch for
> Control.Concurrent.Chan with the concurrent queues added in? Or put it
> up on Hackage?
>
> Fixing concurrent channels and submitting this at all was sort of an
> afterthought but it just made sense to build them on top of the
> queues.
>
> Maybe Hackage is a better place for this until it's better tested in any case.

These kinds of data structures are fiendishly hard to get right, as we 
know from bitter experience.  I'm not suggesting that your 
implementation is wrong in any way - but it's hard to tell whether it is 
right.  For instance, are you sure that it is robust to asynchronous 
exceptions?

I think to replace Chan we would need at the very least plenty of tests. 
  I realise this might sound a bit hypocritical given that we never had 
many tests for Chan, and we've discovered a number of bugs in it over 
the years, but it's a "devil you know" argument.  Let's be sure we're 
not making anything worse.

Personally speaking, I'm not keen on the overly point-free style in your 
code, which I find hard to read.

Again you can take this as my opinion if you want, but I think STM is 
the way forward.  Correctness is *far* easier, and performance is 
surprisingly good (and we could improve it if necessary).  If you're 
avoiding STM for performance reasons, show me the numbers.

Cheers,
	Simon