OS X kqueue based WatchService

[Michael Hall]

On Jun 24, 2013, at 6:46 AM, Alan Bateman wrote:

> 
> I saw your mail to macosx-port-dev on the same topic. Are you saying  that the kqueue call blocks in the kernel for several seconds that you can't explain? 

During the part of the LotsOfEvents test that begins processing events.
It creates 4096 files.
The test waits a second to try and build up a backlog, apparently attempting to cause the overflow event for some implementations. I don't kqueue should overflow.
It goes into the 
drainAndCheckOverflowEvents(watcher, ENTRY_CREATE, n);
to verify it processes all 4096 events or gets an overflow.
That does
       WatchKey key = watcher.poll(15, TimeUnit.SECONDS);
which returns immediately as some of the creates have accumulated.
It processes the events and then does this...
            key = watcher.poll(2, TimeUnit.SECONDS);        
I'm assuming to give the watch service implementation to queue up more events if they haven't all been processed. kqueue usually only seems to have process 30-45 or so at this point. For some reason during this two seconds kqueue does nothing The test fails for not having overflowed or processing all events.
After the exception is thrown, kqueue resumes posting events until the code actually shuts down after the error. It appears to come out of the 'block' like something has been released, but what?
  
> Also, I can't quite tell why you are calling kevent64 with a timeout of 5 seconds. Is this to workaround something else? 
This is what the code I based my native on did. After two timeouts it quits. For the testing I'm doing so far this has been no problem. For longer use that will probably have to change, I am not actually using this for anything yet. It does allow clean shutdown of the kqueue daemon for testing. 
I have shortened the timeout to 1 second in testing and it then does not block but returns a couple times with no events passed from the kernel. So if it is blocking it isn't my code but the the kernel queueing that is blocked? It is not processing in this time period for some reason - while the AbstractWatchService is being polled for results - about 3 seconds or so int total.

> 
> Assuming you are extending AbstractWatchService "framwork" then the thread should be blocked waiting for events without any timeout. The timeout might nothing to do with the issue you are seeing, I'm only asking about it as I don't quite understand why it is is needed.

Did that explain the test and my timeouts?

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130624/b4a12388/attachment.html