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

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-05-11 17:59:12

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

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

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.

Best Regards, Johan
-- 
View this message in context: http://www.nabble.com/Review-Request%3A-future-library-%28Gaskill-version%29-tp16600402p17178502.html
Sent from the Boost - Dev mailing list archive at Nabble.com.