----- Original Message ----- From: <k-oli@gmx.de> To: <boost@lists.boost.org> Sent: Saturday, February 28, 2009 2:48 PM Subject: Re: [boost] [threadpool] new version - withreschedulingofcurrenttask
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,
Soory, I should be more precise (condition not been possible to be satisfyed by a task)
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.
I know that. I have already signaled that this is good and useful.
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.
Ok, I see now the danger. IMO we need just to document that condition::operator()() should not block. If the function block it will block the thread. That's all. Vicente