Re: [boost] [threadpool] new version - withreschedulingofcurrenttask

Subject: Re: [boost] [threadpool] new version - withreschedulingofcurrenttask
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-02-28 08:58:13

----- Original Message ----- 
From: <k-oli_at_[hidden]>
To: <boost_at_[hidden]>
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