On 09/02/2021 15:13, Dominique Devienne via Boost-users wrote:
I think choosing a better framework for your use case would make your life awfully easier. Grand Central Dispatch works very well on Mac OS and FreeBSD, and is built into the system. The port of GCD (libdispatch) to Linux is acceptable. On Windows, you want the Win32 thread pool, totally different API, but does the same thing.
Thanks for your answer Niall. But sounds to me that what you are proposing is a large project in and of itself, versus tweaking a portable Boost.Asio-based existing program, to use less memory.
I agree that the learning curve for a new API will be quite steep initially. But GCD's API is quite nicely designed, it's intuitive, and it "just works". I can't say that the Win32 thread API is as nicely designed. It *is* very flexible and performant, but a lot of it is "non-obvious" relative to GCD's API design. On the other hand, if you implement a GCD based implementation, you'll #ifdef in a Win32 thread API implementation quite easily.
I've thought myself of a few approaches, but none seem very appealing, and some likely would stall / block some task (via cond-vars for example), starving ASIO of some of its threads, so less than ideal.
Surely I'm not the only one who ever tried something like this, no?
This is the beauty of GCD-like implementations. You don't need to think about load nor scheduling, except in the highest level. You just feed work to GCD, tell it the priority for each work item, GCD figures out how best to execute it given your system's *current* conditions. In other words, if half your CPUs are currently at 100%, GCD _only_ occupies the other half of your CPUs. It automatically scales up, or down, concurrency according to your workload e.g. if your work item stalls in a sleep, or a syscall, GCD automatically notices and increases concurrency. If there are too many work items currently running for system resources, GCD automatically notices and decreases concurrency. This is very nice, and getting ASIO to do the same is a lot of extra work.
You may find the unfinished low level prototype platform abstraction of
these facilities at https://github.com/ned14/llfio/pull/68 https://github.com/ned14/llfio/pull/68 useful to study when designing your own integration. It works well on GCD and Win32 thread pools. Its native Linux backend is not usable yet. I hope to send it WG21's way for study before April.
I'll have a look, out of curiosity. But I need Windows/Linux portability, and as outlined above something a bit more approachable for a mere mortal like me.
If you ignore the Linux native backend i.e. assume LLFIO_DYNAMIC_THREAD_POOL_GROUP_USING_GCD=1 or _WIN32=1, you'll note that the implementation reduces down to not much code at all. There is approximately a one-one relationship between GCD and Win32 thread API calls. My suggestion is concentrate on GCD, and use my code in the PR to "translate" the GCD APIs to their equivalents in the Win32 thread API. You may want to try out a little toy prototype to get a feel for the GCD API. I think you'll find you like it. apt install libdispatch-dev should do it. Apple have good API documentation for it on their website. Niall