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

Subject: Re: [boost] Boost.Fiber review January 6-15
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2014-01-10 02:19:53

2014/1/9 Vicente J. Botet Escriba <vicente.botet_at_[hidden]>
>
> 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<Clock, Duration
>

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