Johan Torp <johan.torp@gmail.com> 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 -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL