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

Subject: Re: [boost] [threadpool] mixture of recursive invokation and fibers?
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-11-05 02:47:02

----- Original Message ----- 
From: "Oliver Kowalke" <k-oli_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, November 05, 2008 7:58 AM
Subject: [boost] [threadpool] mixture of recursive invokation and fibers?

>
> hello,
>
> Using fibers in the threadpool in order to enable fork/join comes with 
> some difficulties.
>
> My idea is to use recursive sub-task invokation as default and fiber only 
> in some special cases.
>
> 1.) parent-task locks a mutex and sub-task has also to lock the mutex -> 
> using recursive_mutex
>
> 2.) sub-task waits for signal of parent-task (condition variable) the 
> recursive invokation of sub-task do not work. In this case I would suggest 
> that the sub-task should be executed in a fiber.
>
> task< R >::get() - does recursive invokation of sub-task
> task< R >::get( new_context() ) - does execute the sub-task in a new fiber
>
> What do you think about this?

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