tevent in multithreaded programs
jlayton at samba.org
Fri Jan 30 13:27:14 MST 2015
On Fri, 30 Jan 2015 21:19:03 +0100
Volker Lendecke <Volker.Lendecke at SerNet.DE> wrote:
> On Fri, Jan 30, 2015 at 03:02:53PM -0500, Jeff Layton wrote:
> > That's basically what Simo said too on IRC. His suggestion was:
> > - create a pipe, a list and a lock
> > - dispatch the accept to a workqueue thread
> > - once the accept is done, acquire the lock and add the new fd to the list
> > - drop the lock and then write to the pipe
> > - pipe event handler reads and discards all of the pipe data then
> > acquires the lock and adds all of the fds on the list to the tevent
> > context
> > ...I think that sounds pretty reasonable, and it's a lot simpler than
> > locking across multiple threads. It also means that we can use
> > tevent_wait too and avoid any locking in the event loop unless
> > we're pulling entries off the list.
> Sounds like a plan. Do you really need the "main list"?
> Can't you just write the fd number into the pipe? While it's
> in transit, its ownership might be a bit undefined, but you
> might get away without mutexes.
Yeah, I thought about that...
We may need to register more listeners dynamically as well as connected
sockets and they'll use different tevent_fd_handler_t functions. Still,
we might be able to get away from having to deal with a list by sending
all of the info along the pipe. I'm pondering how to do that safely...
> Can you give me a hint why you want to dispatch the accept?
> Do you have to do significant work between the accept(2)
> call and handing it back to the main loop?
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.
Jeff Layton <jlayton at samba.org>
More information about the samba-technical