l...@gnu.org (Ludovic Courtès) writes:
> Hi Peter,
>
> Peter TB Brett <pe...@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 <pe...@peter-b.co.uk>
Remote Sensing Research Group
Surrey Space Centre
