<div>I agree with Steve, there are definitely situations where using libevent in multithreaded apps makes sense.  My only complaint is exactly what Steve mentioned in his earlier post regarding the use of a pipe/socketpair for inter-libevent thread communication.  I have a main thread listening for inbound connections which then hands the request off to a worker thread.  I generally create 2 * cores number of threads and load balance the inbound requests across them.  Each worker thread runs its own event loop and handles communications with many clients at once.  The worker performs all the communication necessary to fulfill a given client request. </div> <div><br>FWIW, I have a wrapper around the pipe-style message passing that works well for me available at <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.weirdness.net/code/libevent/" target="_blank"> http://www.weirdness.net/code/libevent/</a>.  I've been meaning to document it but I haven't got around to it yet. </div> <div> </div> <div>Andrew<span class="sg"></span></div><br> <div><span class="gmail_quote">On 4/13/07, <b class="gmail_sendername">Steven Grimm</b> <<a href="mailto:sgrimm@facebook.com">sgrimm@facebook.com</a>> wrote:</span> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Martin Hedenfalk wrote:<br>> I'm sorry if the above seems harsh, but I really don't see the point <br>> in implementing a multi-threaded libevent server.<br><br>I can answer that, since I converted memcached from single- to<br>multi-threaded: even if each request completes in a very short time,<br>pile enough of them up in a short period of time and you'll run out of <br>capacity on one CPU. Adding threads lets you make full use of a<br>multiprocessor machine without having to split your application up into<br>separate processes. Splitting into multiple processes not only<br>duplicates whatever constant overhead each instance of your app has, but <br>if the application needs to have globally shared state, you're looking<br>at something like a shared memory region or mmapped file with the same<br>locking issues you have in a multithreaded app.<br><br>As for how to do it, my approach is documented on the libevent home page <br>(or rather, there's a link there to my explanation) so I won't repeat<br>myself. But I will say it's working well for us -- our memcached<br>instances are handling close to twice the request volume they used to be <br>able to handle when they were single-threaded, and they still have<br>plenty of capacity to spare.<br><br>-Steve<br><br>_______________________________________________<br>Libevent-users mailing list<br><a href="mailto:Libevent-users@monkeymail.org"> Libevent-users@monkeymail.org</a><br><a href="http://monkey.org/mailman/listinfo/libevent-users">http://monkey.org/mailman/listinfo/libevent-users</a><br></blockquote></div><br>