Re: Delimited continuations to the rescue of futures

[Peter TB Brett <peter@peter-b.co.uk>]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi Peter,
>
> Peter TB Brett <peter@peter-b.co.uk> skribis:
>
>> This is going to sound like a daft question, but: is there any reason
>> that the thread that calls 'touch' needs to be the same thread that
>> calls its continuation?
>>
>> I.e. why does there need to be a special "main thread"?  Can't "picking
>> up a job blocking on touch" just be another task allocated to the
>> thread pool?
>>
>> Rubbish diagram:
>>
>>        Thread A                 Thread B
>>        --------                 --------
>>    Creates a future F             ...
>>          ...                 Starts computing F
>>      Touches F                    ...
>> Starts computing future G         ...
>>          ...                 Finishes computing F
>>          ...              Continues job that touched F
>>
>>
>> Is this not a plausible approach?
>
> It is, IMO.  This is what ‘wip-nested-futures’ currently does.
>
> What Mark said is that, you could imagine a case where computing G
> actually takes much longer than computing F.  In that case, he suggested
> that Thread A computes F.

Okay, I'm *really* confused now.  In the scenario that I've diagrammed
before, why does it matter how long G takes to compute?

> However, as I said, I’m not really convinced by this argument.
> Normally, both F and G are contributions to a larger computation.  It
> shouldn’t matter which one completes first, as long as threads are kept
> busy.

I clearly don't understand the objection, so I can't really comment
either way.  I would quite *like* to understand it -- I'm very
interested in doing practical parallel computations with Guile -- , so
is there any chance that you would be kind enough to explain like I'm
five or something (possibly with diagrams)?

                          Peter

-- 
Peter Brett <peter@peter-b.co.uk>
Remote Sensing Research Group
Surrey Space Centre