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