Hi Mark, Mark H Weaver <m...@netris.org> skribis:
> l...@gnu.org (Ludovic Courtès) writes: > >> Mark H Weaver <m...@netris.org> 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’.