Proposal: Control.Concurrent.Async

Simon Marlow marlowsd at
Tue Jun 12 12:58:41 CEST 2012

On 08/06/2012 17:31, Thomas Schilling wrote:
> I fixed the docs a tiny bit in:
> Other comments:
>    - Module introduction is missing.

Now added.

>    - There are no tests whatsoever.  I would like to have a few stress
> tests that throw lots of asynchronous exceptions to make sure that
> exception masking etc behaves correctly.

Also added, including a couple of stress tests.  (but the test coverage 
isn't great, I'll try to improve it in due course)

>    - Why is there no waitAnyCancel?
>    - Same with waitEitherCancel

Both added.

I think that now addresses all the comments that people had.

There's one more change I'm thinking about: perhaps instead of

   wait      :: Async a -> IO (Either SomeException a)
   waitThrow :: Async a -> IO a

we should reverse the naming scheme, rename waitThrow to wait and wait 
to something else (waitCatch?).  Rationale: waitThrow seems to be the 
version we need most often, and it's simpler to use.

   wait      :: Async a -> IO a
   waitCatch :: Async a -> IO (Either SomeException a)

Thoughts? Better names for waitCatch?

Latest Haddocks:



> On 8 June 2012 09:37, Simon Marlow<marlowsd at>  wrote:
>> I'd like to add a higher-level concurrency API to the base package. This API
>> has grown while I've been working on examples for my book, and I'm convinced
>> that we should have something like this in the standard libraries.  Here's
>> the API I propose:
>> In fact it already exists in at least two packages on Hackage: 'async' and
>> 'threads'.  My version is a superset of both of these, except for a few
>> small differences (which are up for discussion, of course).
>> One good reason to have this package is that it avoids some common pitfalls,
>> such as forgetting to handle exceptions in your child threads.  In the Async
>> API, you get to choose whether to (a) receive the result as 'Either
>> SomeException a', or (b) have the exception re-thrown in the waiting thread.
>>   You don't get to ignore it altogether.
>> Another common pitfall avoided by this library is accidentally leaving
>> threads running in the background.  This is handled by withAsync:
>>   withAsync :: IO a ->  (Async a ->  IO b) ->  IO b
>> the child thread is always cancelled (i.e. killed) when the second argument
>> returns or throws an exception, if it hasn't finished already.
>> I'm opening this up for discussion so that we can tidy up any inconsistent
>> details and add any functions that people feel are missing.  Naming is
>> obviously up for discussion too.
>> Cheers,
>>         Simon
>> _______________________________________________
>> Libraries mailing list
>> Libraries at

More information about the Libraries mailing list