EXPERIMENTAL: tevent_kqueue support

[Jeremy Allison]

On Tue, Feb 26, 2013 at 01:35:58PM -0800, Jeremy Allison wrote:
> On Tue, Feb 26, 2013 at 09:39:16PM +0100, Stefan (metze) Metzmacher wrote:
> > Am 26.02.2013 20:53, schrieb Jeremy Allison:
> > > On Fri, Feb 22, 2013 at 08:46:31PM +0100, Stefan (metze) Metzmacher wrote:
> > >>
> > >> 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.
> > > 
> > > Ping ! Wonder where you are with this ? I have some OEMs
> > > that would like to see this finished so we can get the
> > > epoll fix into a winbindd release.
> > > 
> > > Is there anything more I can do to help ?
> > 
> > I'll try to propose a patchset for master tomorrow,
> > it would be good to get some feedback then.
> > 
> > In the meantime it would be good if you could take a look
> > at my comments to this:
> > 
> > TODO: Regression test to ensure that a tevent backend can cope with
> > separate read/write events on a single fd.
> > ...
> > TODO: why (fde_wcount - fde_count < 256) ???
> >       if we get TEVENT_FD_WRITE we should not block
> >       we should also not read if we don't get TEVENT_FD_READ,
> >       because this will block.
> > 
> > https://gitweb.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=610afde264816ece80fcdaca13d39ab3bf86c7b7
> 
> That code was already written carefully to do exactly what
> it does :-).
> 
> Without using threads it's really easy to get yourself
> blocked on a pipe. I'll have to do more testing to see
> if it's true that writable is cleared when a pipe is
> full.

Ok, I have something that works at least with poll
and correctly detects pipe full without blocking
in a single threaded process. Needs to do the
same with select and epoll of course.

If you want to propose the existing patchset including
this test (which proves the multi-fd change works
with epoll) I'll create an additional patch on
top that splits the callbacks out into 4 separate
ones that should work cleaner.

Jeremy.