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