From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-05-30 10:58:55
-----BEGIN PGP SIGNED MESSAGE-----
On Friday 30 May 2008 10:44 am, Anthony Williams wrote:
> Johan Torp <johan.torp_at_[hidden]> 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
I in believe Johan's operator||, the value of the returned future logically
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)
-----END PGP SIGNATURE-----
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk