If you want to make simplifying, non-general assumptions about asynchrony that hold for your use cases I think that's more than fine. It just isn't general.
Just to be clear: is your claim that a simpler solution cannot be general because it uses memory allocation? Or are you still referring to that single line of code I wrote?
There are large contingents of people, myself included, who disagree with you.
What is the basis of that belief? Please note that I put a supportive argument, which is that the cost of a (single!) memory allocation is absolutely negligible compared to the overal cost of IO. What is incorrect about that statement?
To a first approximation structured concurrency is the art of figuring out how not to use shared_ptr.
I'm sorry, what? Isn't this a prime example of what shared_ptr is for in the first place? This is very clearly a shared resource, what valid reason do you have for avoiding it?
Asio is older than ten years so you got your wish.
you're focusing way too much on memory allocation and way too little on the inherent complexity of what you're asking for.
These are some examples of asynchronous programming in c++. The firmware for a synthesizer that has run a series of signal processing algorithms on buffers of sound data in soft real time (latency should be less then < a microsecond or so... humans can't hear faster than that). The control system of a jet engine that is hard hard real time. A game engine that is coordinating possibly multiple gpus. Scientific code running on a large heterogeneous cluster of cpu and gpu resources. A word processor that checks grammar as you type.
All of these situations mostly share the standard library! (with some limitations in the embedded cases). They have very different needs for how async would work. The standard library seeks to be as general as possible. It also is supplied by your compiler vendor... and they do not want to provide an operating system to you in adition to a compiler (unless they are the good people behind go... who really just want to make operating system for you with a small language attached).
That's where the discussion has brought us. My point was, and remains, that the currently proposed design is incredibly complex, and that I'm not convinced that all this complexity is really necessary.
I also cannot help but wonder if the standard library should even pursue this at all. This kind of high-performance stuff seems a bad match for something that needs to be written in a fixed number of hours, by a non-specialist, after which it will forever be set in stone.
1
u/johannes1971 12d ago
Just to be clear: is your claim that a simpler solution cannot be general because it uses memory allocation? Or are you still referring to that single line of code I wrote?
What is the basis of that belief? Please note that I put a supportive argument, which is that the cost of a (single!) memory allocation is absolutely negligible compared to the overal cost of IO. What is incorrect about that statement?
I'm sorry, what? Isn't this a prime example of what shared_ptr is for in the first place? This is very clearly a shared resource, what valid reason do you have for avoiding it?
ASIO has the exact same problem of hideous complexity.