Re: [Guile-commits] GNU Guile branch, stable-2.0, updated. v2.0.1-92-gf4e45e9

Re: [Guile-commits] GNU Guile branch, stable-2.0, updated. v2.0.1-92-gf4e45e9

[Ludovic Courtès]

Hello Andy!

"Andy Wingo" <wingo@pobox.com> skribis:

> commit f4e45e91f265429ad1c42d3905dd3c05a0bc0924
> Author: Andy Wingo <wingo@pobox.com>
> Date:   Thu May 26 18:14:32 2011 +0200
>
>     lazily init futures worker pool
>     
>     * module/ice-9/futures.scm (%workers, %create-workers!)
>       (create-workers!): Define a mechanism to spawn off the future threads
>       only when the first future is created.
>       (make-future): Call create-workers! here.

[...]

>    "Return a new future for THUNK.  Execution may start at any point
>  concurrently, or it can start at the time when the returned future is
>  touched."
> +  (create-workers!)

Wouldn't it be more efficient to instead do:

  (if (null? %workers)
      (%create-workers!))

Once the workers are created, that would leave 0 function calls.

Thanks,
Ludo'.

Re: [Guile-commits] GNU Guile branch, stable-2.0, updated. v2.0.1-92-gf4e45e9

[Andy Wingo]

Heya :)

On Wed 08 Jun 2011 23:05, ludo@gnu.org (Ludovic Courtès) writes:

> "Andy Wingo" <wingo@pobox.com> skribis:
>
>>    "Return a new future for THUNK.  Execution may start at any point
>>  concurrently, or it can start at the time when the returned future is
>>  touched."
>> +  (create-workers!)
>
> Wouldn't it be more efficient to instead do:
>
>   (if (null? %workers)
>       (%create-workers!))
>
> Once the workers are created, that would leave 0 function calls.

Possibly, but isn't there a race condition if you do that though?
Consider two calls to make-future from different threads, before the
workers set has been spawned.

Andy
-- 
http://wingolog.org/

Re: [Guile-commits] GNU Guile branch, stable-2.0, updated. v2.0.1-92-gf4e45e9

[Ludovic Courtès]

Hey!

Andy Wingo <wingo@pobox.com> skribis:

> On Wed 08 Jun 2011 23:05, ludo@gnu.org (Ludovic Courtès) writes:
>
>> "Andy Wingo" <wingo@pobox.com> skribis:
>>
>>>    "Return a new future for THUNK.  Execution may start at any point
>>>  concurrently, or it can start at the time when the returned future is
>>>  touched."
>>> +  (create-workers!)
>>
>> Wouldn't it be more efficient to instead do:
>>
>>   (if (null? %workers)
>>       (%create-workers!))
>>
>> Once the workers are created, that would leave 0 function calls.
>
> Possibly, but isn't there a race condition if you do that though?

Oops, you’re right, sorry.

Thanks,
Ludo’.