Boost logo

Boost :

From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2008-05-30 11:56:58

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 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 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 futures
> which is only exposed the wait for any/all mechanism. The
> promise-fullfillers does not only notify their own condition, they traverse
> 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.


Anthony Williams            | Just Software Solutions Ltd
Custom Software Development |
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

Boost list run by bdawes at, gregod at, cpdaniel at, john at