Re: [boost] [threadpool] new version - with reschedulingofcurrenttask

Subject: Re: [boost] [threadpool] new version - with reschedulingofcurrenttask
From: k-oli_at_[hidden]
Date: 2009-02-28 08:48:30

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