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