tevent in multithreaded programs

[Jeff Layton]

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!
-- 
Jeff Layton <jlayton at samba.org>