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

From: Richard Hodges (hodges.r_at_[hidden])
Date: 2021-02-10 11:54:24

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

> On 10/02/2021 09:19, Richard Hodges via Boost-users wrote:
>
> > As far as I am able to tell from attending some of the meetings, the
> > motivation for changes amongst certain actors in WG21 seems to me to be
> > driven by either malice or willful ignorance of the impact on the user
> > community.
>
> I think this too strong. People are sent by their employers to represent
> their employer's interests on WG21. I can't think of a major tech
> multinational whose representatives have not voiced serious concerns
> about how poorly Networking maps onto their platform's proprietary
> networking technologies, which is true, but equally very few of them
> have been willing to fund a reference implementation which does improve
> that mapping AND is completely portable to all the other platforms. They
> have accepted that critique of their critiques, and everybody has
> (mostly) moved on.
>
> 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.

>
> I don't think malice nor wilful ignorance is behind the churn in
> Executors. Rather, if WG21 gets it wrong, it's a huge footgun, so they
> rightly won't progress it until its done. Everything which depends on it
> is therefore blocked.
>
> I would also remind everybody that there was an option to progress the
> blocking only API of ASIO into the standard which could have been
> achieved quickly, but Chris elected not to do so at that time. I think
> he was right in that choice, had the blocking API been standardised, it
> would be unlikely the async API would have been revisited quickly.
>

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.

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