AIO: Switching from thread pools to io_uring

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

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.
Hurd will probably need to keep the old implementation indefinitely. 

It would also adds the complexity to probe and use a dispatch mechanism to 
find out the required minimum kernel, along with test infrastructure to
check both implementations.

My view is POSIX AIO is for standard conformance, so I am not sure we
should really invest on it.