Imagine a database trying to solve

    SELECT client_id, invoice_id, invoice_status, invoice_date
    FROM invoices
    WHERE client_id IN (123, 567) AND invoice_status != 'PAID';

Imagine that there is an index for client_id.

The DB engine can scan the index, finding all the pages in the table that contain rows with one of those two client_ids in.

It requests these pages as soon as it finds them in the index.

It scans the pages in the order it finds them completed, though, which can be a completely different order than it requested them in.

Asynchronous I/O is only useful if you have something else you can be doing while you wait for file-data to arrive. For example, if you can do calculations on the part of the file you've already read while you wait for the rest to arrive, or if you can process data for one client while data from a different client is in-flight. Databases are a good example - usually they're handling queries for multiple clients at once, and even within a query they can be reading from multiple places simultaneously (like the individual tables involved in a JOIN).

If your program needs to read in an entire JSON blob (for example) before it can do anything, or if it only does light processing on each individual part (like adding up a column of a CSV file) then async I/O probably isn't going to help.

Which would actually work nicely with a fibres library, so you can yield while you're waiting for the io to complete.

You can for example read from multiple files simultaneously.

You can also build web servers that read from disk as part of the request handling, without having to do blocking file reads. Before io_uring, this scenario would get absolutely horrible performance as the whole thread would lock down while waiting for the file read. Now you can do other things concurrently.

it looks like in the future it might be a better way of implementing khttpd by handing over from a userspace control program the accept->read->sendfile->close sequence of async operations to the kernel