"Peter Dimov" <pdimov@pdimov.com> writes:
Johan Torp:
is_ready doesn't trigger the callback, so this won't work.
OTOH, I think is_ready should trigger the callback, even for the "run extra work in wait()" thread pool use case.
ready() should trigger a separate "ready callback", since its semantics are not the same.
(f1 || f2).ready :- f1.ready || f2.ready (f1 || f2).wait :- wait_for_any(f1, f2)
Interesting thought. An is_ready() query is certainly not a blocking wait, so shouldn't call the wait callback. A "ready callback" would allow a scheduler to priotize the task without taking over the waiting thread. This goes along with something mentioned earlier about flagging a future as "needed" in order to trigger lazy evaluation, or prioritize the task in a thread pool.
(Ignoring the problem in which f1 completes with an exception and f2 is still active.)
I think that's a non-problem. If f1 completes with an exception, f1 is ready, so (f1 || f2) is ready and should propagate the exception, regardless of the state of f2. This is the same logic as if f1 completes with a value. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL