Am Saturday 28 February 2009 13:59:02 schrieb vicente.botet:
tp::task< int > t1( boost::this_task::get_thread_pool< pool_type >().submit( boost::bind( & fibo::par_, boost::ref( * this), n - 1) ) );
t1.get(); // rescheduling if t1.get() would block == until t1.get() would nont block other items from the pool channel are executed.
The problem with this approach is that the task can not wait on a condition without blocking the worker thread, No - it does not block the worker thread (as you can see in directory examples -> fork_join.cpp) the worker thread executes the next items from the queue until the blocking task is ready.
This is is exactly the role of reschedule_until(), poll a condition and do something else when the condition is not satisfied. Where is thedanger? Could you give an example?
First this is already implemented (see pool::reschedule_until_() will be executed from the internal future if the wait functions of this future would block). If a user does aprovide a blocking call inside condition::operator()() the the worker thread is blocked and this is not wanted. regards, Oliver