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
> 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
Thx - I'll correct this soon (including adding namspace).
> Could we say that we can have thread specific schedulers and multi-threaded
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 >
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
> 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::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
Thx - I think of what should be the next steps (together with boost.task).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk