Re: [boost] [threadpool] mixture of recursive invokation and fibers?

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