marlowsd at gmail.com
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: https://github.com/simonmar/async/pull/1
> Other comments:
> - Module introduction is missing.
> - 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
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?
> On 8 June 2012 09:37, Simon Marlow<marlowsd at 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:
>> 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.
>> Libraries mailing list
>> Libraries at haskell.org
More information about the Libraries