Obviously, if task N blocks on a future you can then reschedule task A, but if it doesn't then you don't get that opportunity. If task N waits for another event to be triggered from task A (e.g. a notify on a condition variable) then it will never get it because task A is suspended, and so the pool thread will deadlock *even when task A is ready to run*.
What about this idea: instead of spawning a new thread still use fibers which will not migrated to other worker-threads. Nonblocking functionality of future::get() is moved into a public available function: template< typename Condition > void threadpool::yield( Condition cond) { BOOST_ASSERT( tss_worker_.get() ); // only worker-threads allowed while ( ! cond) current_fiber_->yield(); } Because thread::conditions don't provide a try_wait() a semaphore should be used (bool semaphore::try_wait() ). ... semaphore sem ....; ... pool.yield( bind( & semaphore::try_wait, ref( sem) ) ); ... regards, Oliver -- GMX Download-Spiele: Preizsturz! Alle Puzzle-Spiele Deluxe über 60% billiger. http://games.entertainment.gmx.net/de/entertainment/games/download/puzzle/in...