Re: [boost] Re view Request: future library (N2561/Williams version)

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2008-05-12 02:41:59

Johan Torp <johan.torp_at_[hidden]> writes:

> Nice work! Let's hope we can all agree on a best interface - and get it
> standardized directly :)

Yes, I hope so.

> Anthony Williams-3 wrote:
>> 
>> * Finally, I've added a set_wait_callback() function to both promise and
>>   packaged_task. This allows for lazy-futures which don't actually run the
>>   operation to generate the value until the value is needed: no threading
>>   required. It also allows for a thread pool to do task stealing if a pool
>>   thread waits for a task that's not started yet. The callbacks must be
>>   thread-safe as they are potentially called from many waiting threads
>>   simultaneously. At the moment, I've specified the callbacks as taking a
>>   non-const reference to the promise or packaged_task for which they are
>> set,
>>   but I'm open to just making them be any callable function, and leaving
>> it up
>>   to the user to call bind() to do that.
>> 
>
> If you haven't, please read my concerns about direct callbacks in
> http://www.nabble.com/Review-Request%3A-future-library-%28Gaskill-version%29-to16600402.html

I have read your comments. My primary reason for including this came from
thread pools: if you know that the current thread (from the pool) is blocked
on a future related to a task in the pool, you can move it up the queue, or
maybe even invoke on the blocked thread. Braddock suggested lazy futures, and
I think that's also an important use case. For one thing, it shows that
futures are useful without thread pools: you can use them in single-threaded
code.

> Anthony Williams-3 wrote:
>> 
>> I've left the wait operations as wait() and timed_wait(), but I've had a
>> suggestion to use wait()/wait_for()/wait_until(), which I'm actively
>> considering.
>> 
>
> I like timed_wait because that's the same name as in condition_variable.
> wait_until could be confusing - one might think the thread will wait until
> the specified time regardless of the future is set or not. time_limited_wait
> or wait_max_time are further alternatives.

This was alongside a suggestion that we change the names for
condition_variable waits. The important part was the separation of
timed_wait(duration) vs timed_wait(absolute_time) with distinct names, so it
was clear which you were calling, and you wouldn't accidentally pass a
duration when you meant a fixed time point.

We could go for timed_wait_for() and timed_wait_until(), but they strike me as
rather long-winded. Maybe that's a good thing ;-)

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