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 <mtho...@strcpy.net> 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 majord...@freehaven.net with
> unsubscribe libevent-users in the body.
>
