Re: Delimited continuations to the rescue of futures

[Ludovic Courtès]

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
busy.

Thanks,
Ludo’.