On Wed, 10 Feb 2021 at 13:34, Niall Douglas via Boost-users < boost-users@lists.boost.org> 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@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212