There has been some discussions about exposing a wait-callback in futures, a hook which is executed whenever someone calls wait. One of the motivations has been to efficiently re-use threads within a thread pool when a task is waiting on a future. The idea is to execute another task in the future::wait() call to avoid thread context switching and to need less worker threads. I've presented some arguments why this might cause unexpected problems. Here is a very crude draft of an alternative thread-pool interface which would allow thread re-use but in an explicit way. Let launch_in_pool come in two flavours, one without surprising thread re-use and one with explicit support for it. I hope the interfaces are self-explanatory. template<class R> future<R> launch_in_pool(function<R()> task); template<class R> future<R> launch_in_pool(function<R(thread_pool& pool)> task); /// The thread_pool class is only to be used by code executed by worker threads class thread_pool { template<class R, class F> future<R> submit_child_task(const F& child_task); enum yield_type {YIELD_TO_CHILD_TASK, YIELD_TO_RELATED_TASKS, YIELD_TO_ANY_TASK}; /// Waits until all child tasks are ready void yielding_wait(yield_type yt); }; Thoughts? Johan -- View this message in context: http://www.nabble.com/-thread-pool-futures--Explicit-yielding-tp17606225p176... Sent from the Boost - Dev mailing list archive at Nabble.com.