Proposal: Control.Concurrent.Async

[Twan van Laarhoven]

On 15/06/12 10:07, Simon Marlow wrote:
> On 14/06/2012 13:12, Sjoerd Visscher wrote:
>> On Thu, 14 Jun 2012 12:42:51 0100, Simon Marlow <marlowsd at gmail.com> wrote:
>> On 13/06/2012 22:58, Sjoerd Visscher wrote:
>>  > > (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.
>>
>> Actually, that is what I expected too. So, this is not the way to use
>> concurrently?
>>
>> concurrently3 m1 m2 m3 = (((v1, v2), v3) -> (v1, v2, v3)) <$>
>>    concurrently (concurrently m1 m2) m3
>
> So what bothered me about this is that it makes 4 threads when I would expect 3,
> and also the asymmetry looks strange.  However see below.


For your enjoyment / horror, I present my implementation of Concurrently that 
uses a single MVar, and exactly one thread per concurrent action. The code is at 
https://gist.github.com/2938456 .

It uses an  MVar (IO (Maybe a)), i.e. each worker thread can post a new action 
that can be done to combine the results; and in the end you hopefully get a 
value of type a.

I'm sure that the code could be improved a lot.



Twan