Re: [Libevent-users] About what's coming to libevent 1.5/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? _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 Hi Nick, thanks for replying! Since I'm too new in async event notification world, all I'm doing right now is read and study all possible technologies and paradigms, and trying understanding them. I know the best way to do that is start hacking on them, but since my project is still under designing phase, hence my doubts. I do think this is the right abstraction I need to my project, and it would be very nice to have this on 1.5/2.0 release :) But as writing this mail, another doubt emerged. Let's suppose I have one acceptor thread with it's event base loops waiting on network events to listen and then forward them to a thread pool abstraction layer. If I did it using a fifo buffer (i.e. a fifo linked list) passing it's fd's to the thread pool, this could be possible with each thread having it's event loop and thus not receiving spurious events from fd's each are handled on the others threads from the pool? Or maybe the best way is having one event loop base to all thread pool, each thread receiving it's fd's events without spurious wakeups? Is this abstraction your talking about on the next release (1.5/2.0)? Andd the last one, with the 'linux eventfd backend', could this be accomplished? I mean, my acceptor thread could just be 'throwing' new events to the thread pool with this eventfd thing? Thanks again for all you attention and patience. Best regards, Raine ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
[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
