[Libevent-users] About what's coming to libevent 1.5/2.0
Hi! I'm starting a project in which I would like to use asynchronous event notification in a multi-threaded server. I've been following libevent releases and it's extensive use on a lot of other projects like memcached, etc since many years ago and always thought it would be the best lib for async for my purposes. But recently I've found libev (http://software.schmorp.de/pkg/libev.html) and it's great features (http://cvs.schmorp.de/libev/README) and performance (http://libev.schmorp.de/bench.html). But, since, libevent is, apparently, most used in a lot of other projects, I'm giving credits to it besides libev features. What make me post here to ask if it's possible to you (libevent staff) to share what it's coming (features and theorical-release-date) on the next release (dunno if will be called 1.5 or 2.0). I've been reading your mailing lists a long time ago and following all threads about multithreaded questions like having an acceptor thread which delivers fd's to another threads to process request. Basically my project design will be based on a pool of threads waiting to events on fd's 'listened' on one or more acceptor threads. I found this explanation posted on your home page (http://monkeymail.org/archives/libevent-users/2007-January/000450.html) about multithreaded use of libevent, but pipe() is not the way I though in passing messages from one thread to another, even the fd's from acceptors to the thread-pool. Do you think that in the next release 1.5/2.0 this behavior should be well implemented, instead of using libev features any time soon? I would like to thank you for your effort in having this great lib, so programing in Unix-land for async events it's that hard! Thanks and best wishes to all of you! Best regards, Raine PD: Sorry for the bad english... :( ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] About what's coming to libevent 1.5/2.0
On Sat, Jan 17, 2009 at 01:11:17PM -0800, Raine Fan wrote: [...] What make me post here to ask if it's possible to you (libevent staff) to share what it's coming (features and theorical-release-date) on the next release (dunno if will be called 1.5 or 2.0). The easiest way to see what's been done for 2.0 is to check out svn trunk at https://levent.svn.sourceforge.net/svnroot/levent/trunk/libevent There's a pretty extensive changelog there already, though there's more stuff planned. I've been reading your mailing lists a long time ago and following all threads about multithreaded questions like having an acceptor thread which delivers fd's to another threads to process request. Basically my project design will be based on a pool of threads waiting to events on fd's 'listened' on one or more acceptor threads. I found this explanation posted on your home page (http://monkeymail.org/archives/libevent-users/2007-January/000450.html) about multithreaded use of libevent, but pipe() is not the way I though in passing messages from one thread to another, even the fd's from acceptors to the thread-pool. Do you think that in the next release 1.5/2.0 this behavior should be well implemented, instead of using libev features any time soon? _Which_ behavior exactly? I can't tell for sure from your write-up what feature it is that you want. Are you talking about the libev - fast intra-thread communication between multiple event loops (with optional fast linux eventfd backend). thing? Looking at the source, it seems that it does use pipe everywhere except on Linux. Is it the _abstraction_ here that you had in mind; the ability to wake up a looping event base from another thread in a safe, generic, and platform-optimized way? Something like that would indeed be cool for 2.0. Heck, I think I'll go hack up the basic implementation now. yrs, -- Nick ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
