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.
Let's say your program wants to list a directory and sort by mtime, or size. You need to stat all those files, which means reading a bunch of inodes. And your directory is on flash, so you'll definitely want to pipeline all those operations.
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.
> I objected to the statement that it would make all programs faster / simpler
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.
> 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.
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).
True. But as soon as your program wants to list two directories and knows both names ahead of time, you have an opportunity to fire off both operations for the kernel to work on simultaneously.
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.
My read of that paragraph was that they meant existing asynchronous programs can be simplified, due to the need for less workarounds for the Linux I/O layer (e.g. thread pools to make disk operations appear asynchronous are no longer necessary.) And I agree with that; asynchronous I/O had a lot of pitfalls on Linux until io_uring came around, making things much worse than strictly necessary.
In general I totally agree that a synchronous program will be way simpler than an equivalent asynchronous one, though.
You can use io_uring as a synchronous API too. Put a bunch of commands on the submission queue (think of it as a submission "buffer"), call io_uring_enter() with min_complete == number of commands and once the syscall returns extract results from the competion buffer^H^H^Hqueue. Voila, a perfectly synchronous batch syscall interface.
You can even choose between executing them sequentially and aborting on the first error or trying to complete as many as possible.
More efficient? Yes. Simpler? Not really. A synchronous program would be simpler, everyone who has done enough of these know it.