On 10/02/2021 03:26, Cristian Morales Vega wrote:
On Tue, 9 Feb 2021 at 14:56, Niall Douglas via Boost-users
wrote: Had ASIO been constructed after these became common, it would undoubtedly have been designed around them. As it stands, some of us on WG21 are hoping to target a Networking v2 design which is based around GCD-type designs for C++ 26 or 29.
You are killing me. We got Networking delayed from C++20 to C++23 (hopefully) just to get it deprecated in C++26?
Nobody said anything about deprecation. "Orthogonal" would be a better description, and you choose whichever Networking suits your problem best. Same as iostreams being perfectly fine for 95% of file i/o, but for some problems it's a really poor fitting solution.
What does Chris think about this? He is arguably been open to changes to Networking TS. Why don't you aim directly for such a "Networking v2", maybe for C++26 (by now I don't mind waiting another 3 years), and skip "Networking V1"?
Chris thinks that what is broadly envisaged for Networking v2 isn't particularly useful for the average C++ developer. It would suit people with specialised needs only, in his opinion. I would only have a weak disagreement with that opinion, it does make sense, from a certain perspective, and it's certainly no showstopper for me personally. I have always been a strong supporter that we only standardise existing practice. My biggest objection to present Networking v1 is how much has been changed through design by committee from original ASIO. The present Networking v1 is very far away from standard practice, and most of the changes have not been, in my opinion, for the better. Traditional ASIO was much better, in my opinion. Pre-covid we had expected that Networking would ship for 23. Many feel that won't be possible now due to covid's impact on productivity, not least because the Executors saga keeps on turning, and WG21 is about to refactor it yet again, and that will have yet more knock on effects on Networking which probably means it will slip to 26.
I am not going to pretend to get the details, but I understand there are a lot of more or less related moving parts (executors, io_uring, GCD, continuations...). So if it gets delayed so be it, we already have ASIO for the time being. But in 2021 work on trying to get something in C++23 with the idea of deprecating it on C++26 sounds... strange.
ASIO is a throughput maximising based design designed around latency unpredictable i/o. If you have that problem to solve (e.g. HTTP servers facing public internet), it is probably the best *portably available* design currently known. If you have other needs, then the ASIO design becomes increasingly less appropriate. Most of the concerted opposition to Networking v1 comes from the tech multinationals on WG21 because they care most about non-public intra datacenter networking mixed with parallelised compute within strictly bounded response times, for which using ASIO is substantially below what's achievable, hence Facebook funding libunifex, or Apple funding GCD, or Google funding Executors, or Netflix funding BSD pthread pools, and so on. A lot of the rage and anger from certain members of the C++ community has been disproportionately directed at a tiny subset of those opposing Networking v1 on WG21, what they have not realised is how much broader based, but also much weaker than is supposed, that opposition actually is. Everybody I know of is trying their best to support and aid Chris in getting Networking v1 done, even if they personally would not be strongly in favour of what it has mutated into since it started standardisation. Most of that mutation has been imposed by committee, very little of it with preexisting direct empirical experience, and it's absolutely no fun to be on the receiving side of that. He's done a ton of work to get it this far, and absolutely nobody wants Networking to become the next Filesystem. I know I was certainly dismayed when it began to look like the 23 ship date could slip to 26, and I can't think of anyone else who wouldn't be dismayed as well. Niall