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
>> 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
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
> 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
> 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 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