Twan van Laarhoven
twanvl at gmail.com
Fri Jun 15 22:04:13 CEST 2012
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
>> 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
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.
More information about the Libraries