Re: [boost] [future] Early draft of wait for multiple futures interface

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-05-30 10:58:55

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
> 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-----