EXPERIMENTAL: tevent_kqueue support

[Jeremy Allison]

On Wed, Feb 27, 2013 at 06:39:15PM +0100, Stefan (metze) Metzmacher wrote:
> Am 27.02.2013 17:58, schrieb Jeremy Allison:
> > On Wed, Feb 27, 2013 at 07:02:43AM +0100, Stefan (metze) Metzmacher wrote:
> >> Am 26.02.2013 22:44, schrieb Jeremy Allison:
> >>> On Tue, Feb 26, 2013 at 01:35:58PM -0800, Jeremy Allison wrote:
> >>>>
> >>>> 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.
> >>>
> >>> Yep. Just confirmed with junk code. poll returns
> >>> writable on a pipe fd even if writing to such a
> >>> pipe would block.
> >>>
> >>> That means that for this test we can't always
> >>> prioritize writes over reads, as we just end
> >>> up blocked in the callback. That's why the
> >>> callback code is written as it is, I'm
> >>> assuming a pipe can hold 256 btyes without
> >>> blocking.
> >>
> >> If we get POLLOUT without being able to write 1 byte
> >> without blocking, we have a problem.
> >> That's the whole point of having POLLOUT at all...
> >>
> >> Can you post your junkcode example?
> > 
> > As I mentioned later, I had a bug :-).
> > 
> > Got it working now. I'll re-do the test patch
> > to work without the hack and re-post it.
> > 
> > You can then rebase it on top of the merged
> > patchset.
> 
> I have a specific test for the full buffer thing now...
> 
> https://gitweb.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=dbbf42e848d2d125a2d35916bc2482a51ee3994b
> 
> It generates the attached strace output, which shows that all backends
> behave the same.
> 
> Maybe it would be better to have the test with 2 events
> as a separate test instead of modifying the existing one?

Sure, I'm happy with that as an additional test.

I just want to make sure it is always tested so
we don't ever break it :-).

Jeremy.