Proposal: Add tryReadChan to Chan

Simon Marlow marlowsd at
Fri Dec 3 16:13:37 CET 2010

On 01/12/2010 00:25, Mitar wrote:
> Hi!
> On Wed, Dec 1, 2010 at 12:55 AM, Antoine Latter<aslatter at>  wrote:
>> All of this really feels like what STM is good at. It might help if you
>> explained why TChans are not well suited to your task.
> Because it has too much overhead (I haven't tested it for my
> particular application but it is based on comment for isEmptyChan). I
> understand that Chans are more lightweight and once isEmptyChan was
> deprecated I discovered that for my purposes (non-blocking read) I do
> not need isEmptyChan and that code can be written without problems
> isEmptyChan has (mostly because there is a subtle change in
> semantics).

Chan and TChan have approximately the same performance, based on some 
simple benchmarks we did back when we implemented STM.  All the 
exception-safety stuff slows down Chan - those modifyMVars aren't cheap.

It's possible things may have changed though, it was a while since we 
did those measurements.

If you have many threads beating on the same Chan, then in that case the 
STM version may be a lot slower because it doesn't have the 
single-wakeup property that MVars have.  That's the tradeoff.


More information about the Libraries mailing list