Mark - do you mean that you *do* use a dedicated "accept()or" thread than passes newly accepted sockets to one of N worker threads, that then the chosen worker thread registers the FD with it's own event_base
^^^ what I don't want to do OR that each worker performs independent accept() - by monitoring the shared listener FD on its own event_base ? ^^^ that's how I do it now and how I would like to continue doing it with libevent On Wed, Oct 10, 2012 at 11:29 AM, Mark Ellzey <[email protected]> wrote: > On Tue, Oct 09, 2012 at 06:22:08PM -0400, Programmist Setevik wrote: > > 1) "Main" thread that does something like this, (pseudo code): > > > > for ( all configured listen ports) { > > FD = socket() > > bind() > > set non-block() > > listen > > add FD to a list > > > > } > > > > for (configurable # of worker threads) { > > > > ctx = malloc() > > ctx->ev_base = setup event_base > > add each FD , register it with ctx->ev_base // mark the FD as > "listener" > > FD so we know to acept() on EV_READ > > start worker thread, passing it the ctx // so that each thread has its > own > > ev_base > > > > } > > ... > > do whatever, w/o ever touching any of the ev_bases and/or accesing any of > > the sockets/FD that are registered with > > ev_bases > > ... > > This is actually the best way of doing things in libevent IMO. I do the > same thing in most of my code, it minimizes lock contention, and > generally makes things easier to debug. > > I use evconnlisteners, where the callback gets the fd, doesn't accept > the connection, but passes off the fd to a thread. Since each thread > spawns with its own event_base, use that base to call > bufferevent_socket_new(). > That accepted socket is now tied to the event_base on that thread. > *********************************************************************** > To unsubscribe, send an e-mail to [email protected] with > unsubscribe libevent-users in the body. >
