Re: Boost.Asio as "thread-pool": How to apply back-pressure?

From: Dominique Devienne (ddevienne_at_[hidden])
Date: 2021-02-09 15:13:40

On Tue, Feb 9, 2021 at 3:56 PM Niall Douglas via Boost-users <
boost-users_at_[hidden]> 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