On Thu, Jan 9, 2014 at 1:11 AM, Oliver Kowalke
- 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).