Sorry, it is on the sf.net of course. Here is the link: http://sourceforge.net/tracker/index.php?func=detail&aid=2014953&group_id=50884&atid=461324
Chris Brody wrote: > Where is the patch? > > On Thu, Jul 10, 2008 at 2:20 PM, Valery Kholodkov > <[EMAIL PROTECTED]> wrote: >> 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 >> -- Best regards, Valery Kholodkov _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
