revisiting "how do you use aio and epoll together"

following the discussion at How do you use AIO and epoll together in a single event loop?.

There are in fact 2 "aio" APIs in linux. There's POSIX aio (the aio_* family of functions), included in glibc and libaio developed I believe by RedHat (?), the io_* family.

The first one allows registration of notification requests via aio_sigevent aiocb member. That can be easily integrated with ppoll()/pselect() event loops. If you want to integrate POSIX aio with epoll() then you need to translate the signal into an event on a dummy fd (a 开发者_开发百科pipe maybe) and listen for it with epoll, while catching the signal either in a classic manner or with ppoll/select. How safe is the first choice (normal sighandlers), depends on application. And maybe on epoll but i'm not fully aware of its internals. May I safely assume that if I have an epoll based app and I want to add POSIX aio support then I'm screwed? This was my question.

The second AIO implementation, libaio - can be used indeed with eventfd() (struct iocb having an aio_resfd member that is expected to be zero or an eventfd to deliver AIO results to). But it's not by the book. POSIX-specified, that is.

I dream of myself being a *BSD user where everything is clear. You have the POSIX AIO and kqueue() support for AIO events. Crystal clear. Like many other things.

---

note you CAN use POSIX aio with epoll, there's signalfd(2) it creates a file descriptor that you can then use to be notified of signals in an epoll based loop.

Also the second aio API is supposed to eventually be what glibc bases it's implementation of POSIX aio on, it's just not quite there yet... (I don't know if anyone is working on it either)