Hello,A nice library, I've had to re-implement similar functionality, so this would be useful!
Some questions about the waiting combinators:
1. I was expecting that `waitAny` and friends, would also return the result of the first computation that completed. Is there a reason not to do so?
2. Is `waitAny` waiting for one of the Asyncs to complete _successfully_ or is throwing an exception considered as completion? I am guessing the former, with `waitAnyThrow` providing the latter functionality?
3. As far as I understand, `waitAny` does not stop the other asyncs (it'd be nice to add this note to its documentation, explicitly). If that's the case, perhaps it's type should be: `waitAny :: [Async a] -> IO (a,[Async a])`, so that we can keep on waiting for more asyncs, if needed?
-Iavor
On Fri, Jun 8, 2012 at 1:37 AM, Simon Marlow
<marlowsd@gmail.com> 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:
http://community.haskell.org/~simonmar/async-stm/Control-Concurrent-Async.html
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@haskell.org
http://www.haskell.org/mailman/listinfo/libraries