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@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users