Oliver Kowalke-2 wrote:
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.
Yes I have already remarked this fact. If we restraint to having only one scheduler instance running on a thread, we can transform these static calls to polymorphic calls. This will opens the introduction of schedulers external to the library. The call of virtual functions could decrease the performances of some functions, but a test on the enumeration should be equivalent.
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.
Well if I understand, up to now you have implemented non-migrating fibers. The idea could be to introduce migrating fibers on a separated class, and don't decrease the performances of a simple tool. I have yet another question. I understand we need fibers::mutex and fibers::condition_variable, but could you explain why do we need a separated fibers::lock_guard and fibers::unique_lock template classes? Why the ones from Boost.Thread are not usable in the fiber context, at the end the Mutex parameter can be any model of lockable. Best, Vicente -- View this message in context: http://old.nabble.com/new-library-boost.fiber-in-vault-tp26453013p26467888.h... Sent from the Boost - Dev mailing list archive at Nabble.com.