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-09 02:11:32

2014/1/8 Eugene Yakubovich <eyakubovich_at_[hidden]>

> Some suggestions:
> - Maybe this is something that should be handled in a separate fiber
> pool library but I'd like to be able to specify multiple threads for
> affinity. This is useful for when a fiber should be bound to any one
> of threads local to a NUMA domain or physical CPU (for cache sharing).
>

yes, that's what I implement in another library (for instance
thread-pining; used in
performance tests of boost.context)

> - I dislike fiber_group. I understand that it parallels thread_group.
> I don't know the whole story behind thread_group but I think it
> predates move support and quick search through the mailing list
> archives shows there were objections about its design as well. I
> specifically don't like having to new up fiber object to pass
> ownership to add_fiber. fiber object is just a handle (holds a
> pointer) so it's a great candidate for move semantics. It maybe best
> to take out fiber_group altogether. What's a use case for it?
>

I've added fiber_group only to mimic the boost.thread API - I've never used
thread_group so I've no problems to remove fiber_group from the API (if
desired).

>  > - What is your evaluation of the implementation?
> - Can I suggest replacing the use of std::auto_ptr with
> boost::scoped_ptr? It leads to deprecation warnings on GCC.
>

OK

> - 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 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?

> 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).

>  > - What is your evaluation of the documentation?
> Ok but, like others have said, could be improved. ASIO integration is
> poorly documented.
>

OK