Re: [boost] new library boost.fiber in vault

Subject: Re: [boost] new library boost.fiber in vault
From: Oliver Kowalke (k-oli_at_[hidden])
Date: 2009-11-22 11:35:52

Vicente Botet Escriba wrote:
> Ok I see. I'll put all the conflicting stuff on the namespace fibers, but I
> would let Non-member template function make_fiber() on boost namespace. BTW,
> it is not clear in the reference documentation on which namespace this
> function is in.
>   
It's not a big thing to move make_fiber() etc. to boost namespace.
I did found any advice in the boost documentation what is the preferred 
way.
> I have found also an incoherence between the implementation and the
> documentation concerning the classes disable_interruption and
> restore_interruption. They should be defined on the this_fiber namespace,
> but I found them declared on boost::fibers. Am I missing a using
> declaration?
>   
Thx - I'll correct this soon (including adding namspace).
> Could we say that we can have thread specific schedulers and multi-threaded
> schedulers?
>   
Would be nice but requires a careful design.
> I see that you plan to implement other scheduler features, e.g. taking care
> of priorities. I see also that  there are some functions that depends on the
> scheduler class. Of course we can have a single scheduler class that would
> take care of all the scheduler intricacies, but I think that it will
> interesting to explore the possibility to have several models of a Scheduler
> concept, and see if making this possible don't would decrease the
> performances or even if this could allow to improve them. If we would have
> specific schedulers, the current scheduler class would be just one of them,
> and should be named with its current specific purpose.
>
>   
I plan to implement several scheduling algorithms selectable via an 
enumeration passed to the ctor of the scheduler class.
Another possibility would be to do make scheduler to an template and the 
template argument specifies the scheduling algorithm (implementation).

template< typename Strategy >
class scheduler;

scheduler< round_robin > rr_sched;
scheduler< bfs > bfs_sched;

This would break the usage of boost::this_fiber::yield() for example, 
because the functions in namespace boost::this_fiber access the 
scheduler via a static member and need to know the exact type of the 
scheduler.
> Maybe it is worth considering migrating and non-migrating fibers respect to
> threads and schedulers. What do you think?
>   
Sounds reasonable if we can get a correct working implementation.

> What about having fiber specific storage, something like fiber_specific_ptr?
> Would this be possible without breaking the current design?
>
> What about a fiber barrier?
>   
would be nice

> Have you explored how fibers and futures interact?
>   
I'll start to integrate boost.fiber into boost.task:

boost::fibers::scheduler sched;

boost::task::handle< int > h = boost::task::async(
       boost::task::make_task( my_fn), sched);
...

> Let me know if I can help you on any task, I'm really interested in this
> library. 
>   
Thx - I think of what should be the next steps (together with boost.task).

best regards,
Oliver