[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Delimited continuations to the rescue of futures

From: Ludovic Courtès
Subject: Re: Delimited continuations to the rescue of futures
Date: Wed, 21 Nov 2012 22:19:40 +0100
User-agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux)


Peter TB Brett <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:
>> Hi Peter,
>> Peter TB Brett <address@hidden> 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

This is what Mark was concerned about.  I’m inclined to think that it
doesn’t matter much.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]