[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: Tue, 20 Nov 2012 20:20:02 +0100
User-agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux)

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.



reply via email to

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