Re: Delimited continuations to the rescue of futures

[Ludovic Courtès]

Hi Mark,

Mark H Weaver <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:
>
>> Mark H Weaver <address@hidden> skribis:
>>
>>> I guess the one remaining concern I have is that if there are any
>>> long-running futures in the process, then any 'touch' could take a very
>>> long time to complete, even if the future it is waiting for is a very
>>> short job.
>>>
>>> For example, (par-map - '(1 2 3)) could take several minutes to complete
>>> if (par-map process-image list-of-images) is being done in another
>>> thread.
>>
>> Right.  That’s actually easy to fix, but the advantage of the current
>> solution is that it uses less code.  Anyway, you’re probably right, so
>> I’ll do that.
>
> I'd be very curious to hear about your easy fix, because I couldn't
> think of anything easy.

I think you were right.  :-)

The solution I tried was to have ‘touch’ directly call (process-future!
future) when it’s queued.  The problem arises when the future suspends
itself.  In that case, the calling ‘touch’ has then no way to
distinguish between a waiting future and a queued one, because both have
the ‘queued’ status.  So it ends up re-running the just-queued future,
which fails because it’s in fact waiting.

So I introduced a third state, ‘waiting’, to help with that.  I ended up
with more complex code and, more importantly, a hard-to-debug race
condition (I wish we had tools to help with that...)

Having spent some time on this, I’m inclined to leave things this way.
:-)

WDYT?

Ludo’.