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
