Hello! On Mon, Nov 28, 2005 at 01:24:22PM -0800, christopher baus wrote: >>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.
>The only problem here is that you are doing a frivolous lock if the API >is thread safe (such as sys_epoll). Considering that the app is >probably I/O bound anyway this might not matter. And even if not, I can dispatch *computing* tasks to threads even if I restrict I/O multiplexing to one thread (at a time). >I so suspect the problems of switching to ACE would be worse than >continuing down this route. *nods*. As said, we got bitten by the static FD_SETSIZE as ACE uses it (it does *not* malloc the fd_sets, so we can only handle at most 1024 fds). And ACE uses select which doesn't scale well, while libevent is able to leverage scalable interfaces such as epoll or kqueue. >Christopher Kind regards, Hannah. _______________________________________________ Libevent-users mailing list [email protected] http://monkey.org/mailman/listinfo/libevent-users
