Subject: Re: [boost] [threadpool] mixture of recursive invokation and fibers?
From: Oliver Kowalke (k-oli_at_[hidden])
Date: 2008-11-05 02:55:33
> 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