Boost logo

Boost :

From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2008-05-30 10:44:27


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.

>> Java futures don't have this callback proliferation problem because they
>> are
>> abstract.
>>
>> class future
>> {
>> public:
>> virtual void wait() = 0;
>> virtual bool ready() = 0;
>> };
>>
>
> There are other ways of solving this too, without exposing callbacks.

Can you suggest some?

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk