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