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