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

Subject: Re: [boost] Boost.Fiber review January 6-15
From: Eugene Yakubovich (eyakubovich_at_[hidden])
Date: 2014-01-10 13:11:43

On Thu, Jan 9, 2014 at 1:11 AM, Oliver Kowalke <oliver.kowalke_at_[hidden]> wrote:

>> - While I understand that scheduling algorithm is more internal than
>> the rest of the library, I still don't like detail namespace leaking
>> out. Perhaps these classes should be moved out of the detail
>> namespace.
>>
>
> hmm - interface algorithm is already in namespace fibers. could you tell me
> to
> which class you referring to?

algorithm is in namespace fibers but the arguments and return types
are often in detail namespace.
For example, spawn() takes detail::fiber_base::ptr_t and
get_main_notifier() returns detail::notify::ptr_t.

>
>> - algorithm interface seems to do too much. I think a scheduling
>> algorithm is something that just manages the run queue -- selects
>> which fiber to run next (e.g. Linux kernel scheduler interface works
>> like this). As a result, implemented scheduling algorithms have much
>> overlap.
>
>
> maybe manager would be a better wording?
> the implementations of algorithm (schedulers in the docu) own the fibers
> internal
> data strucutres. the fibers are stored if waiting or but in a ready-queue if
> ready to be resumed.
> what would you suggest?
>
I think there are a couple of things going on inside current
schedulers. One is selecting the next fiber to run (that's the round
robin portion). Another is managing the suspension, resumption, and
waiting of fibers -- that would be a manager portion. I forked the
repo and I'm trying to see if it's possible to separate it. That would
allow someone to write a priority based scheduler and then use it with
both "regular" fibers and asio managed ones. I probably won't be done
with it until next week.

>> Indeed, round_robin and round_robin_ws is almost identical
>> code.
>>
>
> the difference is that round_robin_ws enables fiber-stealing and owns two
> additional
> member-functions for this purpose. the internal ready-queue is made
> thread-safe (concurrent
> access by different thread required for fiber-stealing).

I agree but my point was that b/c the class does too much, there's a
bunch of copy/pasted coded (not related to the run queue).