Re: [boost] [future] Early draft of wait for multiple futures interface

From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2008-05-30 10:34:05

"Peter Dimov" <pdimov_at_[hidden]> 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