<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> As the guy who added thread support to memcached, I feel qualified to answer this one: What libevent doesn't support is sharing a libevent instance across threads. It works just fine to use libevent in a multithreaded process where only one thread is making libevent calls. What also works, and this is what I did in memcached, is to use multiple instances of libevent. Each call to event_init() will give you back an "event base," which you can think of as a handle to a libevent instance. (That's documented in the current manual page, but NOT in the older manpage on the libevent home page.) You can have multiple threads each with its own event base and everything works fine, though you probably don't want to install signal handlers on more than one thread. In the case of memcached, I allocate one event base per thread at startup time. One thread handles the TCP listen socket; when a new request comes in, it calls accept() then hands the file descriptor to another thread to handle from that point on -- that is, each client is bound to a particular thread. All you have to do is call event_base_set() after you call event_set() and before you call event_add(). Unfortunately, you pretty much have to use pipe() to communicate between libevent threads, That's a limitation, and honestly it's a pretty big one: it makes a master/worker thread architecture, where one thread handles all the I/O, much less efficient than you'd like. My initial implementation in memcached used an architecture like that and it chewed lots of CPU time. That's not really libevent's fault -- no UNIX-ish system I'm aware of has an equivalent to the Windows WaitForMultipleObjects API that allows you to wake up on semaphores / condition variables and on input from the network. Without that, any solution is going to end up using pipes (or maybe signals, which have their own set of issues in a multithreaded context) to wake up the libevent threads. -Steve Glen Hein wrote: <blockquote cite="mid00d401c73651$dce4edf0$6401a8c0@GHDualLaptop" type="cite"> <meta http-equiv="Content-Type" content="text/html; "> <meta name="Generator" content="Microsoft Word 11 (filtered medium)"> <style>  </style> <div class="Section1"> Hello,<o:p></o:p> <o:p> </o:p> I am doing research for a project that may follow an event-driven multi-threaded model with heavy disk and network I/O.  The platform will be FreeBSD and Linux.  Overall, we are seeking a C10K solution.  <o:p></o:p> <o:p> </o:p> I started reading through the libevent source and noticed several comments about not being thread-safe.  However, I have seen references to other projects that are multi-threaded and use libevent.  I need to explore libevent and determine if it is viable for my project.  Have there been discussions on threading issues in the mailing list archive?  Is there another source of information on threads and libevent?  <o:p></o:p> <o:p> </o:p> Thanks,<o:p></o:p> Glen Hein<o:p></o:p> <o:p> </o:p> </div> <pre wrap=""> <hr size="4" width="90%"> _______________________________________________ Libevent-users mailing list <a class="moz-txt-link-abbreviated" href="mailto:Libevent-users@monkey.org">Libevent-users@monkey.org</a> <a class="moz-txt-link-freetext" href="http://monkey.org/mailman/listinfo/libevent-users">http://monkey.org/mailman/listinfo/libevent-users</a> </pre> </blockquote> </body> </html>