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

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2021-02-10 12:34:15

On 10/02/2021 11:54, Richard Hodges via Boost-users wrote:

>     Most of what is delaying Networking in the past year or so has not been
>     directly related to Networking (that ship has sailed, the committee has
>     conclusively voted that Networking = ASIO). The present problems are the
>     concurrency model, specifically what and how and why Executors
>     ought/could/should/might be. That's the exact same problem which has
>     bedevilled the Networking proposal since its very beginning, but I want
>     to be absolutely clear that it isn't just Networking being roadblocked
>     by this. Several major proposals are blocked by Executors.
> 
> 
> It seems to me that what is holding up executors is the insistence on
> the sender/receiver nonsense.
> 
> The use case for which seems to be (from looking at the proposals)
> unmaintainable and unintelligible write-once multi-page compound
> statements describing what could easily be expressed in a simple coroutine.

It's not Sender-Receiver. The committee voted on that two years ago and
that's a done deal. Chris has bought into it, ASIO already ships with
support for it, that's water under the bridge.

No to do a horrible over simplification, the current problem is about
what a Scheduler ought to be, and what an Executor ought to be if a
Scheduler is split away from an Executor. They're currently rejigging
the execution policies around a Scheduler-Executor split, and that has
knock on consequences on anything which touches execution policies.

I'm not the right person to say any more detail on this. My opinions on
Executors are widely known (they are not favourable), and I don't keep
up to date with the latest from SG1 in this topic, mainly because doing
so gets me rather angry. If anybody listened to me on this, I'd just
plaster "implementation defined" over most of the entire execution thing
for now, let people actually build working implementations, then look
again later at standardising what emerges from that implementation
practice. I have failed to persuade anybody of that course of action.

> A blocking-only API after half a decade of pontificating would be a
> risible outcome, which would reflect even more poorly on the competence
> of an already distrusted standards committee. 
> 
> We already have a standardised blocking-only API in Berkeley Sockets.
> What on earth would be the point of choosing C++ as the language for
> your program only to have it spend all its time blocked on a socket, and
> dependent on IO-specific mechanisms for cancellation?
> 
> Such a thing does not belong in the standard at all.

Personally speaking, I would have plenty of time for a blocking API
which acts over Coroutines. So, it's blocking from the perspective of
the Coroutine, but it's actually a suspend-resume point and all the
socket i/o across many Coroutines gets multiplexed.

That solution is no ASIO of course, but you could proceed with
standardising it without needing to refer to Executors in any way i.e.
timely progress would be possible.

Niall