----- Original Message ----- From: "Oliver Kowalke" <k-oli@gmx.de> To: <boost@lists.boost.org> Sent: Wednesday, November 05, 2008 8:55 AM Subject: Re: [boost] [threadpool] mixture of recursive invokation and fibers?
Hi Olivier,
I would prefer to go on the direction of a single thread_pool which can be configured by user. Whitch will be the default configuration needs to be found.
The user can enable/disable the fork/join using something like { enable_fork_join fj_enabler; // here get use recursive sub-task invokation { disable_fork_join fj_disabler; // here get blocks } }
The user can enable/disable the fibers using something like { enable_fork_join fj_enabler; // here get use recursive sub-task invokation { enable_fibers fiber_enabler; // here get fibers switch context } // here get use recursive sub-task invokation }
Maybe this approach has some pitfalls I have not explored yet. What do you think?
Vicente
You suggest to privde a mechanism similiar to boost::this_thread::disable_interruption and boost::this_thread::restore_interruption. I don't think we should not do this because some applications need more than one threadpool (piplined architectures for instance) so you will be forced to pass the pool instance to enable_fork_join etc. _____________________ Yes, I'm suggesting that. Could you tell me more about when we need more that one pool (piplined architectures for instance)? Even if this is the case, this do not forbid to have enablers/disablers taking the pool as parameter. If at the end we think that it would be interesting to have a default thread pool we can have namespace the_thread_pool which defines enablers/disablers respect to this default thread pool. Vicente