Question

I have started looking at a new paradigm I didn’t know called asynch IO in Linux.

My goal is to use async IO targeting sockets to write high-performance efficient servers. The reason is that my application is IO-bound.

While searching for more information I came across the following 2 introductions.

1. Posix AIO

2. Linux AIO interface

In a asynchronous framework, the situation I would like to avoid is to create a new thread for each notification I need to process asynchronously since it will kill my application.

My questions are the following:

1. Do the behind-the-scenes of these 2 frameworks address this problem?

2. If yes what would you suggest having in mind socket?

Regards

AFG

Answer 1

None of these are really intended for sockets.

The POSIX AIO interface creates threads that use normal blocking IO. They work with the buffer cache and should in principle even work with sockets (though I’ve admittedly not tried).

The Linux kernel AIO interface does not create threads to handle requests. It works exclusively in “no buffering” mode. Beware of non-obvious behaviour such as blocking when submitting requests in some situations, which you can neither foresee nor prevent (nor know about other than your program acting “weird”).

What you want is nonblocking sockets (a nonblocking socket is “kind of asynchronous”) and epoll to reduce the overhead of readiness notification to a minimum, and — if you can figure out the almost non-existing documentation — splice and vmsplice to reduce the IO overhead. Using splice/vmsplice you can directly DMA from disk to a kernel buffer and push to the network stack from there. Or, you can directly move pages from your application’s address space to kernel, and push to the network.
The downside is that the documentation is sparse (to say the least) and especially with TCP, some questions remain unaddressed, e.g. when it is safe to reclaim memory.