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

From: Richard Hodges (hodges.r_at_[hidden])
Date: 2021-02-10 13:10:55

On Wed, 10 Feb 2021 at 13:34, Niall Douglas via Boost-users <
boost-users_at_[hidden]> wrote:

> 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.
>

Chris included sender-receive into asio out of politeness as far as I can
tell.
I asked him about use cases on two occasions. One during an executors
round-table and another time privately. I won't put any words in
his mouth, because there weren't any.

The Committee certainly has not "bought into it". Discussions continue, with
Ville (IIRC) recently (correctly) suggesting that it be hived off into its
own paper.

What is actually happening is that a vociferous minority interest group is
pushing its own idea of what is fanciful, without regard for the wider user
base.

>
> 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.
>
>
This is what Asio gives us today through a trivial replacement of
a completion token, and it is manifestly _not_ a blocking API if
it involves coroutines.

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.
>

Asio with current asio executors works pretty well, is nicely flexible and
works extremely well with coroutines calling asynchronously
between disparate executor types. I have some demos of this in my
C++ Alliance blog.

Fancy words mean nothing Niall, what is at stake here is C++ being useful
for networking in server applications out of the box. A perfectly
acceptable,
ubiquitous, production tested, solution was proposed by one brilliant
concerned individual. Then a hoard of untalented engineers mobbed
the agenda to push something no-one else wants.

>
> Niall
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>

-- 
Richard Hodges
hodges.r_at_[hidden]
office: [phone]
home: [phone]
mobile: [phone]