... So it has the potential to make a lot of programs much simpler.
More efficient? Yes. Simpler? Not really. A synchronous program would be simpler, everyone who has done enough of these know it.
More efficient? Yes. Simpler? Not really. A synchronous program would be simpler, everyone who has done enough of these know it.
Let's say your program wants to list a directory, if it has nothing to do during that time then there is no point to using an asynchronous model, that only adds costs and complexity.
How do you do that without an async API? Thread pool and synchronous syscalls? That's not simpler.
At no point did I say that these APIs were not useful? I’m literally the person who explained what kind of uses would be simplified by async syscalls.
And you can keep your strawman to yourself. I objected to the statement that it would make all programs faster / simpler, the argument that it would make some simpler or faster is not something I ever argued against.
And I pointed out that even the simplest example you could come up with can in fact be made faster (than implementing sequentially) or simpler (than implementing with threads, which require synchronization) with an async API. So I don't see the straw man.
Pretty much anything that needs to interact with the kernel can benefit from this.
No, you pointed out that a different example could be made faster (and almost certainly at the cost of simplicity, the mention of which you carefully avoided).
> So I don't see the straw man.
That doesn't surprise me.
And even if your program doesn't have any opportunity for doing IO in parallel, being able to chain a sequence of IO operations together and issue them with at most one syscall may still get you improved latency.
Interesting times.
In general I totally agree that a synchronous program will be way simpler than an equivalent asynchronous one, though.
You can even choose between executing them sequentially and aborting on the first error or trying to complete as many as possible.