Greetings! I have written a patch which introduces AIO support to libevent. This allows asynchronous applications to avoid blocking on disk IO, thus giving additional performance boost.
Technically AIO requests are being accumulated in internal libevent queues and submitted to kernel before entering to kqueue/epoll/select/whatever calls. On FreeBSD notification via kqueue is supported, on other platforms default implementation with signal notification supposed to be used. There is also a skeleton for Linux AIO support with notification via eventfd, however I can neither compile nor run it for now without additional stubs, since eventfd was introduced only in glibc 2.8, which is not available for now by default on any distributions (however I might be wrong). I also don't have Solaris anywhere around, so I cannot implement Solaris port support. Therefore I'm looking for a possibility to install pure Linux distribution which I could upgrade to glibc 2.8 and also for a possibility to install OpenSolaris. This could take a long time and moreover I don't hurry, therefore please expect to see a better support for these platforms no less than in three months from my side. I tried to make the API as simple as possible and it doesn't depend on the platform. There are basically 4 functions: event_aio_assign() -- prepares and event structure for monitoring asynchronous IO operation, assigns callback and application context for an event event_aio_read() -- initiates asynchronous read event_aio_write() -- initiates asynchronous write event_aio_cancel() -- cancels asynchronous IO operation Once event_aio_assign() is performed on an event structure, it is possible to invoke event_aio_read(), event_aio_write() to initiate an AIO operation. It is safe to call event_aio_read(), event_aio_write(), event_aio_cancel() in a callback. However it is not possible to operate on buffer while AIO is in progress. Any event base could operate on both normal event structures and event structures, prepared for AIO operations. As an example I have implemented asynchronous gzipper (see aio-test.c). However I found, that this example does not outperform gzip, since benefits of AIO appear themselfs only in specific conditions. One has to deal with multiple buffers to get better performance, which is outside of the scope of the example. I believe AIO support will allow to build pure asynchronous applications and eliminate some of the problems of threaded ones. I now find myself amused playing with this AIO stuff and I'm going to submit additional patches for this feature once I will have something worked out. For support and questions feel free to contact. Good luck and additional performance to your applications! -- Best regards, Valery Kholodkov _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
