AIO: Switching from thread pools to io_uring

[Dhruv McElwaine]

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

I've added a new notification mechanism (tentitivly SIGEV_QUEUE) in the
style of
IOCP and kqueue. An application that uses POSIX AIO would only need to
write
a different `sigevent ` mechanism to get native async file io on all
platforms.

> we will need to keep the old implementation
I've architected the implementation so that there's a clean split between
event_queue.c(responsible for converting POSIX aiocbs to io_uring sqes)
and aio_impl.c(which implements the various SIGEVs, `aio_suspend`,
`lio_listio`, ect).
event_queue.c has a stable ABI, so a thread pool based reimplementation
could be
slotted in at runtime.

> at least Kernel 5.7+
All required features are available on 5.2 and up; the only feature not
available on 5.1
is `IOSQE_IO_DRAIN`, which is needed for a correct `aio_fsync`
implementation.

> It would also adds the complexity to probe and use a dispatch mechanism
to
> find out the required minimum kernel
Hopefully it could be done at load time, but I'm still trying to figure out
how linux's
runtime linking APIs work.

>  test infrastructure to check both implementations
`event_queue.c`s stable ABI means that the same test infrastructure can be
used for
both implementations.

On Wed, 31 Dec 2025 at 11:45, Adhemerval Zanella Netto <
adhemerval.zanella@linaro.org> wrote:

>
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20251231/6b42013f/attachment.htm>