Hello! On Mon, Nov 28, 2005 at 08:57:32PM -0000, christopher baus wrote: >> In fact that's what I do too, after handling I/O in the main program >> didn't work out well enough. Not exactly indeed. Instead we fork/exec off >> some number of helper processes (even with a little separate I/O helper >> binary) and talk a little protocol to them over unix domain sockets. >> They're fast enough so we don't do any shared memory hacks or similar.
>This is one reason why I think it would be nice to reconsider the thread >safety of libevent. There are race conditions with multiple threads >adding events to a poller. While I think it will work with epoll in most >situations, libevent doesn't make this guarantee. For our model we didn't need it. Either we fork, so only the main process (single-threaded) uses libevent, or we make worker threads and only the main thread uses libevent. The workers are synchronized using mutexes, a semaphore (main -> worker) and a pipe (worker -> main) only. >I keep going back and forth between libevent and much heavier solutions >like Doug Schmidt's ACE because of issues like this. ACE uses select in a dumb way, which caused our company quite some pain. Kind regards, Hannah. _______________________________________________ Libevent-users mailing list [email protected] http://monkey.org/mailman/listinfo/libevent-users
