Subject: Re: [boost] [threadpool] new version - with reschedulingofcurrenttask
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
If a user does aprovide a blocking call inside condition::operator()() the the
worker thread is blocked and this is not wanted.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk