3 ms·
> AFAIK kqueue also supports completion based IO using aio_read/aio_write together with sigevent. If you can point to a practical example of a program doing it
by coder543 5y ago
> AFAIK kqueue also supports completion based IO using aio_read/aio_write together with sigevent.
If you can point to a practical example of a program doing it this way and seeing a performance benefit, I would be curious to see it. I did some googling and didn't really even find any articles mentioning this as possibility.
kqueue is widely considered to be readiness based, just like epoll, not completion based.
What you wrote sounds like an interesting hack, but I'm not sure it counts for much if it is impractical to use.
- CodesInChaos 5y agoI don't know if it offers any practical benefits for sequential/socket IO. But AFAIK it's the way to go if you want to do async random-access/file IO.
- funny_falcon 5y agoAfaik, Nginx used this hack for aio on FreeBSD many years. It is superrior to aio on Linux. That is why Netflix used nginx together with FreeBSD. Now nginx could use threads for file io, and linux file performance became ok as well.
- mzs 5y agoIt feels like it's been ten years since I fiddled with this on FreeBSD but EVFILT_AIO worked surprisingly well with aio and kqueue on spinning disk.
- asveikau 5y agoPOSIX AIO uses `struct sigevent` to notify completion. On FreeBSD you can set ->sigev_notify to SIGEV_KEVENT, and ->sigev_notify_kqueue to a kqueue descriptor. As for your "performance benefit" question and nobody using it over readiness based approaches: Well yes. No idea how it compares with a traditional readiness based socket program. But it's kind of not the point either. AFAIK the scenario where POSIX AIO makes most sense is files on disk.