EXPERIMENTAL: tevent_kqueue support

[simo]

On Fri, 2013-02-22 at 12:00 -0800, Jeremy Allison wrote:
> On Fri, Feb 22, 2013 at 08:46:31PM +0100, Stefan (metze) Metzmacher wrote:
> > Hi Jeremy,
> > 
> > >>>>> I've started with a tevent_kqueue implementation
> > >>>>> (just looking at the man page).
> > >>>>>
> > >>>>> It compiles for me on linux with the 2nd HACK patch.
> > >>>>>
> > >>>>> Can you have a look and test it?
> > >>>>>
> > >>>>> @Jeremy: we may want to pick up some of the simplified logic into the
> > >>>>> epoll backend:
> > >>>>>          kqueue_update_fd_event() instead of
> > >>>>>          epoll_add_event/epoll_mod_event/epoll_del_event/epoll_change_event.
> > >>>>
> > >>>> Don't think that will work. The difference between epoll/kqueue
> > >>>> is that kqueue doesn't seem to have the restriction on adding
> > >>>> 2 events with the same fd, which means we'd have to migrate
> > >>>> all the logic in my epoll patch into a epoll_update_fd_event
> > >>>> function, which might get rather messy :-).
> > >>>
> > >>> We already had a epoll_change_event(), which I renamed to
> > >>> epoll_update_event()
> > >>> and used in all places instead of using epoll_{add,mod,del}_event directly.
> > >>>
> > >>> I current epoll patchset is attached, please take a look, but don't push
> > >>> it to master yet.
> > >>
> > >> Ok, I'll run under test and wait for you to confirm you're
> > >> happy.
> > > 
> > > Finally got time to look at this. Needs this additional
> > > patch to compile (but I'm sure you already knew that :-).
> > 
> > Yes :-)
> > 
> > I spend the last days, fixing some bugs that made autobuild unstable
> > when we use the poll backend. (About 30-40 private autobuilds...)
> > 
> > My current work in progress is available under
> > https://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master3-tevent2
> > and
> > https://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-tevent2
> > 
> > I'll try to add some more tests which test the specific behaviors
> > regarding triggered events,
> > e.g. that an event without flags and remaining bytes in the socket
> > doesn't cause
> > a 100% cpu loop and similar things.
> 
> Thanks, I'll take a look !
> 
> My only comment would be that fixing the epoll backend
> to cope with arbitrary errors in system calls to allow
> fallback to poll is probably overkill with modern kernels.
> 
> i.e. does epoll_ctl ever *actually* fail on any modern
> kernel other than when we abuse it by adding the same
> fd multiple times ?
> 
> Are there actual bugs in kernels that we must support
> that cause us to add this complexity to the tevent epoll
> backend ?
> 
> It would be much simpler to make "standard" == epoll
> on Linux and kqueue on *BSD and remove all the fallback
> stuff (IMHO).

+1 if there is a bug on a specific version I rather put pressure on
kernel/distributions to fix it and explain users how to temporarily
select another backend to workaround the problem, but keep the default
on epoll.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>