@kirkshoop first, thanks for writing, developing and making RxCpp publically available! It is obvious, that you put a tremendous amount of work, thoughts and design into it which really pays off for many other projects that chose to adapt and depent on it. :+1:
[..] There is no thread-pool scheduler yet. A thread-pool scheduler requires taking a dependency on a thread-pool implementation since I do not wish to write a thread-pool. My plan is to make a scheduler for the windows thread-pool and the apple thread-pool and the boost asio executor pool.. One question to answer is whether these platform specific constructs should live in the rxcpp repo or have platform specific repos. [..]
I was wondering whether you would be open to a revisit and consider accepting external PR regarding this topic. We'd be happy to help/contribute because managing threads is a latency performance driver for our little library. Before posting a PR, or proposing an API, I wanted to check with you and get your thoughts on this:
Having thread pools is certainly useful and re-using an old/idling thread shaves off the latency from some tens of microseconds to less than a micro-seconds (especially w.r.t. cache locality). At the same time, there are many other requirements like
thread pool grow policy (fixed, increasing, grow/timed-shrinking, ...)
OS independence
thread affinity (aka. 'CPU shielding': pinning a group of threads to the same core)
thread scheduler choice and priority within the given domain (SCHED_OTHER, SCHED_RR, SCHED_FIFO, ...)
naming of individual threads (-> aids debugging/identification)
thread profiling
<_add your requirements_>
...
that some may consider essential, and some other completely superfluous for their application. Also, there are further technical implementation details (e.g. which lock(-free) queue, ring-buffer, ... to use) where people may agree or disagree with based on their application.
Thus, rather than writing an all-encompassing solution that might be hard to bootstrap, to test, to extend, and to maintain, I would reckon that it would be better/cleaner to have a simple template interface that RxCpp calls -- that defaults to the existing solution if none is provided (similar to allocators) -- where the user could provide their own thread-pool implementation, constraints, or wrap around one of the many existing thread-pool implementations.
To avoid v-tables, devirtualisation, and sorts (and their performance penalties), the obvious choice would be to avoid inheritance but to template this e.g. with std::is_invocable and/or even concepts. Crucially, these types of interfaces would require moving the C++ standard adherence of RxCpp at least to C++17, better even C++20 (because of concepts).
I was wondering whether this would fit w.r.t. your roadmap for RxCpp ... :thinking: Your feedback would be much appreciated.
@kirkshoop first, thanks for writing, developing and making RxCpp publically available! It is obvious, that you put a tremendous amount of work, thoughts and design into it which really pays off for many other projects that chose to adapt and depent on it. :+1:
In here you mentioned:
I was wondering whether you would be open to a revisit and consider accepting external PR regarding this topic. We'd be happy to help/contribute because managing threads is a latency performance driver for our little library. Before posting a PR, or proposing an API, I wanted to check with you and get your thoughts on this:
Having thread pools is certainly useful and re-using an old/idling thread shaves off the latency from some tens of microseconds to less than a micro-seconds (especially w.r.t. cache locality). At the same time, there are many other requirements like
SCHED_OTHER,SCHED_RR,SCHED_FIFO, ...)that some may consider essential, and some other completely superfluous for their application. Also, there are further technical implementation details (e.g. which lock(-free) queue, ring-buffer, ... to use) where people may agree or disagree with based on their application.
Thus, rather than writing an all-encompassing solution that might be hard to bootstrap, to test, to extend, and to maintain, I would reckon that it would be better/cleaner to have a simple template interface that RxCpp calls -- that defaults to the existing solution if none is provided (similar to allocators) -- where the user could provide their own thread-pool implementation, constraints, or wrap around one of the many existing thread-pool implementations.
To avoid v-tables, devirtualisation, and sorts (and their performance penalties), the obvious choice would be to avoid inheritance but to template this e.g. with std::is_invocable and/or even concepts. Crucially, these types of interfaces would require moving the C++ standard adherence of RxCpp at least to C++17, better even C++20 (because of concepts).
I was wondering whether this would fit w.r.t. your roadmap for RxCpp ... :thinking: Your feedback would be much appreciated.