Hi,
Peter TB Brett <pe...@peter-b.co.uk> skribis:
> 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?
It would matter in the following case:
Thread A Thread B
-------- --------
creates futures F creates future G
... ...
touches F ...
starts computing G ...
... starts computing F
... finishes computing F
returns F's result ...
... touches G
This scenario is possible with ‘wip-nested-futures’, where a thread that
touches a future picks any pending future, not necessarily the one at
hand.
This is what Mark was concerned about. I’m inclined to think that it
doesn’t matter much.
Thanks,
Ludo’.
