[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
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
Re: [Libevent-users] About libevent-2.0 documentation
Oops, sorry...just correcting...I was talking about using large scale of event_pair structs intead of event-bases. Raine From: Raine Fan raine...@ymail.com To: Libevent-users@monkey.org Sent: Saturday, May 2, 2009 12:46:51 AM Subject: [Libevent-users] About libevent-2.0 documentation Hi Nick/Niels/Libevent staff! Meanwhiloe reading the great documentation of Libevent-2.0 (http://wangafu.net/%7Enickm/libevent-book/) I was a bit confused on some warnings. Could explain in more details, if possible? http://wangafu.net/%7Enickm/libevent-book/Ref4_event.html on 'Stack- and struct-allocated events' When you say that You shouldn’t do this unless you knowthat you’re incurring an actual performance penalty for heap-allocating your events instead of allocating them on the stack, what would be the best way to do it? If I want to scale my app on, lets say 1Millon fd's :-) , do you think that using heap-based allocation could incur in a great performance penalty? Since I'm really new to this kind of programing paradigm (BTW this doc is awesome!), what kind of good tricks/advises could you dispose to us, noobies, for making a good use of libevent to scale our apps to above the C10K paradigm? If we are using multithreaded event-loops, using heap-allocation maybe is the only way to pass info between the threads, or just making a large global statically allcoated array of event-bases and let the threads work consistently on them? Thanks again for the help and support! Regards, Raine ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
