[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost
Subject:    Re: [boost] [threadpool] new version - with
From:       k-oli () gmx ! de
Date:       2009-02-28 13:48:30
Message-ID: 200902281448.30422.k-oli () gmx ! de
[Download RAW message or body]

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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[prev in list] [next in list] [prev in thread] [next in thread]