-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 30 May 2008 10:44 am, Anthony Williams wrote:
Johan Torp <johan.torp@gmail.com> writes:
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.
What does it mean for a shared_future<string> to be "ready and false"?
I view "f1 || f2" as a short-hand for a call to wait_for_any(f1,f2) followed by either f1.get() or f2.get() depending on which was ready first.
I in believe Johan's operator||, the value of the returned future logically corresponds to f1.get() || f2.get() That is, the operator|| is acting more consistently with the usual meaning of operator|| for boolean values, as opposed to just being a short hand way to express a "wait for either future" operation. This kind of confusion is why I don't like operator overloading :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIQBYv5vihyNWuA4URAkhbAKCoZK5pP48ieB+9gSN14GAIhr0UnQCferoj 6tHjtxYhwJYp8GPaimF66KE= =KCnZ -----END PGP SIGNATURE-----