EXPERIMENTAL: tevent_kqueue support

[Jeremy Allison]

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).

Jeremy.