Re: [boost] Boost.Fiber review January 6-15

2014/1/9 Vicente J. Botet Escriba

you can compare X and Y

You are surely right, but I don't see how? Could you show it? implicit conversion to bool through operator bool()

Is there an example showing this on the repository?

...

no its is an implementation in side the framework, e.g. class scheduler which holds the user-defined or the default implementation of the scheduler-impl (default is round_robin)

Could you post here an example at the user level?

sorry - I don't understand your question. boost.fiber contains already two implementations of fiber-schedulers (derived from algorithm) - class round_robin and class round_robin_ws. an instance of class round_robin will be installed by the framework if the user does not apply its own scheduler (via set_scheduling_algorithm()). how the fiber-.schedulers are managed inside the framework is out of scope for the user (because an implementation detail) 00 the user does not have to deal with it.

Why do the user needs to own the scheduler?

in contrast to threads - where the operating system owns the scheduler - there is no instance other the user responsible to own/manage the fiber-scheduler (this includes instannling the default fiber-scheduler) detailed: you can describe a fiber as a thin wrapper around a coroutine - the fiber contains some additional data structures like internal state (like READY, WAITING, TERMIANTED etc.) and a list of joining fibers (waiting on that fiber to terminate). A fiber-scheduler (e.g. a class derived from algorithm) is required to manage the fibers running in one thread - therefore the scheduler isntance is stored in a thread_specific_ptr (this is an implementation detail), hence the fiber-scheduler instance is global for this thread but in other threads you have other fiber-schdulers running. The fiber-schduler itself has two queues (this is true for round_robin and round_robin_ws from the lib) - a queue for suspended fiber waiting on some event ( to be signaled from a sync. primitive or sleeping for a certain time -> internal state is WAITING) and a queue holding ready to run coroutines (internal state is READY). the scheduler deques a fiber from the ready-queue and resumes it. If the user is not satisfied with the features provided by round_robin he can implement its own fiber-scheduler (providing priority ordering) by derving from algorithm and calling set_scheduling_algorithm().

There is no time_duration time. Just duration.

yes - I see you know what I mean ;)

duration can be added to any system_clock::time_point, steady_clock::time_point or whatever timepoint

OK - but the interface of the lib already accepts arbitrary duration types from boost.chrono.