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