Proposal: Control.Concurrent.Async

Michael Snoyman michael at
Fri Jun 8 11:41:29 CEST 2012

On Jun 8, 2012 11:37 AM, "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

What's the advantage to putting this in base instead of a separate package?
If it goes in base, it will make it more difficult to upgrade, and take
longer for this module to be adopted at all. If possible, I'd opt for a
standalone package.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list