Proposal: Control.Concurrent.Async

Simon Marlow marlowsd at gmail.com
Tue Jul 3 14:53:16 CEST 2012


On 18/06/2012 14:56, Ross Paterson wrote:
> On Fri, Jun 15, 2012 at 02:26:51PM +0100, Simon Marlow wrote:
>> On 14/06/2012 16:10, Ross Paterson wrote:
>>> 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.
>
> The list functions have a similar issue: you have to give them the
> right type when you create them if you want them together in a list.
> Perhaps a convenient interface for the multiplexing part would be
>
> data AsyncF a = forall r. AsyncF (Async r) (r ->  a)
>
> instance Functor AsyncF where
>    fmap f (AsyncF a k) = AsyncF a (f . k)
>
> waitSTMF :: AsyncF a ->  STM (Either SomeException a)
> waitSTMF (AsyncF a k) = fmap (fmap k) (waitSTM a)

Good idea.  In fact, I've added a Functor instance for Async itself - it 
required a bit of refactoring but didn't add much overhead.

Cheers,
	Simon




More information about the Libraries mailing list