OS X kqueue based WatchService

[Alan Bateman]

On 19/06/2013 23:39, Michael Hall wrote:
>
> I had done some OS X nio.2 coding for my trz package, see below.
> This had included a kqueue implementation of a WatchService to 
> possibly use instead of the built-in polling one.
Good to hear this, it's been on the list for a while to add a kqueue 
based WatchService implementation (the original Mac port missed it so 
this is why we uses the fallback polling implementation).


> It passed the Basic nio.2 WatchService tests but not the LotsOfEvents 
> one.
> I decided to see if I could get it to put some more time into it, 
> first trying to get it passing the LotsOfEvents test. I changed it in 
> a way that I thought would work but am running into an issue I'm not 
> sure how to address.
> For brevity without throwing in lots of code snippets and debug 
> message logs it goes something like.
> The kqueue native should run on it's own thread. The LotsOfEvents test 
> polls the WatchService with the AbstractWatchService timer invocation. 
> After the first timer expires it processes keys until none and then 
> attempts to timer poll again.
> For some reason from the time the first poll expires to the time the 
> first attempted re-poll expires the code seems to do nothing to keep 
> the process alive.
> A span of about 3 seconds with nothing happening, not even one native 
> event loop running on it's own thread. (Appears to be sitting in the 
> kevent call).
> Prior to this the kqueue native code is processing events at a rate of 
> about 12 events per second.
> Why does the native code seem blocked in the critical part of the test?
LotsOfEvents will stress the implementation, and trigger OVERFLOW events 
too.

I'm not sure that I follow your questions about timers because I 
wouldn't expect the kqueue implementation to use any. Assuming you have 
using the AbstractWatchService "framework" then there will be a 
background thread blocked in kqueue waiting for an event (no timeout as 
the wakeup mechanism will have a pipe registered so that it can be woken 
for registration changes).

So are you following the Solaris implementation? I will guess that the 
kqueue based implementation close to close(-ish) to the Solaris port 
based implementation.

-Alan.