Sure it would be my pleasure. Kqueue allows a read request to be scheduled that is non-blocking on a page fault. Linux always blocks the thread executing read() on a page fault. This is still true using aio_read(), as all that does is run another thread to call read() which blocks. Which is great for small numbers of read requests but scales poorly.
And the bit from the paper that is relevant:
> A non kqueue-aware application using the asynchronous
I/O (aio) facility starts an I/O request by issuing
aio read() or aio write() The request then proceeds independently
of the application, which must call aio error()
repeatedly to check whether the request has completed,
and then eventually call aio return() to collect the completion
status of the request. The AIO filter replaces this
polling model by allowing the user to register the aio request
with a specified kqueue at the time the I/O request
is issued, and an event is returned under the same conditions
when aio error() would successfully return. This
allows the application to issue an aio read() call, proceed
with the main event loop, and then call aio return() when
the kevent corresponding to the aio is returned from the
kqueue, saving several system calls in the process.
OK, so you're talking about AIO and other people here are talking about mmap. If you have working AIO then you can indeed write a fully async server at the cost of extra memory copies.
Read and write system calls have nothing to do with jump instructions causing a page fault by traversing data structures. That is what Redis is all about - in memory data structures available to clients.
And the bit from the paper that is relevant:
> A non kqueue-aware application using the asynchronous I/O (aio) facility starts an I/O request by issuing aio read() or aio write() The request then proceeds independently of the application, which must call aio error() repeatedly to check whether the request has completed, and then eventually call aio return() to collect the completion status of the request. The AIO filter replaces this polling model by allowing the user to register the aio request with a specified kqueue at the time the I/O request is issued, and an event is returned under the same conditions when aio error() would successfully return. This allows the application to issue an aio read() call, proceed with the main event loop, and then call aio return() when the kevent corresponding to the aio is returned from the kqueue, saving several system calls in the process.