Proposal: Control.Concurrent.Async
Simon Marlow
marlowsd at gmail.com
Fri Jun 15 15:26:51 CEST 2012
On 14/06/2012 16:10, Ross Paterson wrote:
> On Fri, Jun 08, 2012 at 09:37:16AM +0100, Simon Marlow wrote:
>> 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.
>
> I'd expect the arguments of cancelWith to be the other way round.
> Then you could say
>
> cancel = cancelWith ThreadKilled
Agreed.
> An alternative, equivalent interface for waitEither and friends would be
>
> waitEither :: Async a -> Async a -> IO (Either SomeException a)
> waitEitherThrow :: Async a -> Async a -> IO a
>
> This might be conceptually simpler, leaving it to the user to decide
> whether to mark the results with Left/Right, or something else, or not.
> Similarly the Async now returned by waitAny and friends could be left
> to the user. That would leave the two sets of functions more in line.
I liked this suggestion at first, but later concluded that it isn't as
nice. The problem is that to convert an 'Async a' to an 'Async (Either
a b)' has to be done when you create the Async in the first place, or
else you have to write some STM code to lift the result. If you're
writing some STM code anyway, then there's little point in using waitEither.
So I think the waitEither and waitAny families complement each other;
waitEither handles the lifting of the results into Either for you, which
is sometimes handy.
Cheers,
Simon
More information about the Libraries
mailing list