[vkka]

... 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.

[masklinn]

I’m guessing they mean that programs which did not want to block on syscalls and had to deploy workarounds can now just… do async syscalls.

[Filligree]

Which is every program that wants to be fast, on modern computers. So...

[aseipp]

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.

[the8472]

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.