OS X kqueue based WatchService
Alan Bateman
Alan.Bateman at oracle.com
Thu Jun 20 04:49:29 PDT 2013
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.
More information about the nio-dev
mailing list