From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-05-30 10:36:52
Peter Dimov-5 wrote:
>> 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
>> work in wait()" thread pool use case.
> ready() should trigger a separate "ready callback", since its semantics
> not the same.
> (f1 || f2).ready :- f1.ready || f2.ready
> (f1 || f2).wait :- wait_for_any(f1, f2)
No, (f1 || f2).ready != f1.ready || f2.ready.
f1 can be ready and false, in which case we need to wait for f2 to become
ready until the composite future is ready.
> Java futures don't have this callback proliferation problem because they
> class future
> virtual void wait() = 0;
> virtual bool ready() = 0;
There are other ways of solving this too, without exposing callbacks.
> but we'd rather like to pass and return futures by value. :-)
What do you mean?
-- View this message in context: http://www.nabble.com/-future--Early-draft-of-wait-for-multiple-futures-interface-tp17242880p17560501.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk