[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 14:36:05 +0100
User-agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux)

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.

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


reply via email to

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