On Tue, Feb 9, 2021 at 3:56 PM Niall Douglas via Boost-users < boost-users@lists.boost.org> wrote:
On 09/02/2021 13:19, Dominique Devienne via Boost-users wrote:
My issue is that Boost.Asio seems to schedule an awful lots of A# and B# tasks, before getting to the C# tasks, [...], and thus using too much memory.
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 abusing Boost.Asio is not ideal here, although it works OK enough, and I'm looking for more pragmatic and immediately applicable advise, if possible. 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? You may find the unfinished low level prototype platform abstraction of
these facilities at 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. Thanks, --DD