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 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)
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 are abstract.
class future { public: 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? Johan -- View this message in context: http://www.nabble.com/-future--Early-draft-of-wait-for-multiple-futures-inte... Sent from the Boost - Dev mailing list archive at Nabble.com.