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:26:47

2014/1/9 Vicente J. Botet Escriba <vicente.botet_at_[hidden]>

> The algorithm class should be called scheduler.

or manager?

> Either his definition is hidden to the user or you don't use detail and
> document all the needed types.
>

usually the user don't have to care but it allows the user to implement its
own scheduler

> Please replace _ws by work_stealing.
>

OK

> Can the user define a specific scheduler that provide the work stealing?
>

yes, as round_robin_ws already does and the class might be a blue print

> Could you show an example of a specific algorithm?
>

class round_robin in the library

> How portable is the priority if it is specific of the scheduler?
>

sorry - I don't get it. inside a thread the fibers are running the semantic
of a priority is the same (because you have only one scheduler dealing with
the priorities)
if you refer to migrating a fiber between threads (e.g. between
fiber-schedulers) the interpretation of priority depends on the semantics
of priority in the fiber-scheduler
the fiber was migrated to.

> I'm sure I'm missing the role of the scheduler. what are the propose of
> the virtual functions.

deriving/overloading

> I have the impression that it implements a lot of things none of them
> related to scheduler. It seems to me that it is the class that is calling
> to the scheduler that schedules. What am I missing?
> I'll continue once I understand what the scheduler algorithm purpose is
> for.
>

please look at my previous email - it contains a rough explanation of
schdulers