Proposal: Control.Concurrent.Async

Simon Marlow marlowsd at gmail.com
Thu Jun 14 13:42:51 CEST 2012


On 13/06/2012 22:58, Sjoerd Visscher wrote:
> Hi Simon,
>
> This a really nice and clean library!
>
> I was wondering if it would be useful to have an applicative interface for the concurrently function? Something like this:
>
>    (page1, page2, page3)
>      <-  runConcurrently $ (,,)
>      <$>  Concurrently (getURL "url1")
>      <*>  Concurrently (getURL "url2")
>      <*>  Concurrently (getURL "url3")
>
> More code here: https://gist.github.com/2926572

I'm not sure about this.  What you get with the above code is a strange 
nesting of concurrently calls, whereas what the user might expect is for 
it to behave like the existing concurrently but on 3-tuples instead of 
pairs.

I like the idea of generalising to arbitrary Traversable structures 
though.  Maybe we could provide something like

   doConcurrently :: Traversable t => t (IO a) -> IO (t a)

I haven't tried to write it, but it looks like it ought to be possible.

Cheers,
	Simon



> Thanks,
> Sjoerd
>
> On Jun 8, 2012, at 10:37 AM, Simon Marlow 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
> --
> Sjoerd Visscher
> https://github.com/sjoerdvisscher/blog
>
>
>
>
>




More information about the Libraries mailing list