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. regards, Oliver -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger