AIO: Switching from thread pools to io_uring

[Florian Weimer]

* Adhemerval Zanella Netto:

> On 31/12/25 07:09, Florian Weimer wrote:
>> * Dhruv McElwaine:
>> 
>>> Currently, glibc's aio implementation relies on a thread pool to provide
>>> parralelism. With io_uring turning 6 tomorrow, I have started work on a
>>> reimplementation of aio based on io_uring. Would it be worth trying to
>>> finish it off and merge it into glic proper?
>> 
>> If it can produce the required semantics, that would be really nice.
>> (We probably need more AIO tests, possibly using the FUSE test framework.)
>
> There is also the question whether POSIX AIO interfaces are really used
> in face of more recent libraries that already leverage io_uring. POSIX
> aio also has some design problems, like complex notification mechanism 
> (either using SIGEV_SIGNAL/SIGEV_THREAD or aio_suspend) and cancellation.

Applications still need fallback to something else because io_uring is
not widely available (and sometimes blocked by security policies).

> And we will need to keep the old implementation for the time being, since
> to fully support POSIX AIO we will need at least Kernel 5.7+ for 
> aio_read/aio_write/lio_listio (IOSQE_ASYNC/IORING_OP_ASYNC_CANCEL) and
> maybe even a more recent kernel to fully support metadata operations.

Right.

> Hurd will probably need to keep the old implementation indefinitely. 

I would expect asynchronous interfaces to exist at the Mach level
because it's the more foundational interface (from a programming
model).