From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-05-30 12:13:31
----- Original Message -----
From: "Anthony Williams" <anthony.ajw_at_[hidden]>
Sent: Friday, May 30, 2008 5:56 PM
Subject: Re: [boost] [future] Early draft of wait for multiple
> Johan Torp <johan.torp_at_[hidden]> writes:
>> Anthony Williams-4 wrote:
>>>> No, (f1 || f2).ready != f1.ready || f2.ready.
>>>> f1 can be ready and false, in which case we need to wait for f2 to
>>>> 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 was talking about future operators. That is the composite future we got
>> from f1 || f2, not selecting the first one which is ready. This should
>> become ready when it has an evaluated value of true or false.
> Are you envisaging "f1 || f2" as a short-hand for "f1.get() ||
> f2.get()" that may not need to wait for both? I see that as very
> limited utility, since it only works for future<R> where R can be used
> with ||.
> My "f1 || f2" is a future operator that returns a composite future. It
> is the future that is subject to ||, not the returned value.
>>>> There are other ways of solving this too, without exposing callbacks.
>>> Can you suggest some?
>> I already have, all of my proposals has solved this without exposing any
>> external callbacks. I propose adding a parent-child relationship to
>> which is only exposed the wait for any/all mechanism. The
>> promise-fullfillers does not only notify their own condition, they
>> their future's parents and notify them too.
> OK. This is similar to what I've done with detail::future_waiter. I
> could probably extend it to provide a full future that had the
> semantics of the future_or I posted earlier. I'll have a look next week.
Do you mean that future_waiter will be public and not a implementation
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk