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

Subject: Re: [boost] Boost.Fiber review January 6-15
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-01-10 02:43:41

Le 10/01/14 08:19, Oliver Kowalke a écrit :
> 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.
I will come later with this point.
>
> 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.
>
I understand why I was lost by the algorithm function description. The 
fact that you showed the algorithm interface make me though that  this 
is an extension point pf the library. You must remove this a just say 
that there are two scheduler.
>> 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().
>
>
Hrr. So its is an extension point, but for advanced users that know how 
to do it looking at the code.
You mustn't document the interface of the algorithm class even in this 
case.
>> 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.
>
Don't forget that my point was related to time_points.

Vicente