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