Re: [Libevent-users] Multi-threading question

[Programmist Setevik <programmist.setevik@xxxxxxxxx>]

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 <mthomas@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.