tevent in multithreaded programs

[Simo]

On Fri, 2015-01-30 at 15:38 -0500, Jeff Layton wrote:
> On Fri, 30 Jan 2015 21:35:32 +0100
> Volker Lendecke <Volker.Lendecke at SerNet.DE> wrote:
> 
> > On Fri, Jan 30, 2015 at 03:27:14PM -0500, Jeff Layton wrote:
> > > No, not really, but it's possible that we may have multiple listener
> > > sockets, as well as activity on the connected sockets. The basic idea
> > > is to keep as much out of the event loop as possible, as we want to keep
> > > it able to deal with new socket events.
> > > 
> > > It may turn out to be much ado about nothing, of course. Maybe accept
> > > handling and registering a new event is so lightweight that it's better
> > > to do it in the context of the event loop and call it good enough. I
> > > still like the basic idea of parallellizing as much as possible though.
> > 
> > If you want to optimize at that level I think tevent is too heavy-weight
> > for you. You should do direct epoll with a cache of malloc'ed state
> > records. tevent involves talloc and thus malloc which is too expensive
> > to really squeeze the last cycle out of the code. The main performance
> > killer for you will be the tevent_add_fd user space code. tevent is
> > really, really handy for complex async code, but if you have a lot of
> > variation in which sockets to handle, you got a problem. Long-running
> > connections, sure, web-like traffic, no.
> > 
> 
> These should be pretty long running connections. I'm probably just
> falling prey to trying to overthink how to do this. :)
> 
> I think I may just go with doing the accept in the event handler, but
> still have the connected sockets dispatch their activity to the
> workqueue. That's certainly simpler for now, and we can switch to
> dispatching the accepts to the workqueue later if it turns out that
> it's needed.
> 
> Thanks for the help so far!

FWIW this is what I do in GSS-Proxy :-)
(Main loop handles connections, work queue do work)

Simo.

-- 
Simo Sorce