Any native WatchService implementation planned on Mac OS X for JDK9?

[Michael Hall]

On Aug 9, 2014, at 2:58 PM, Christopher Brown <christopherbrown06 at gmail.com> wrote:

> Hi Michael,
> 
> I'm looking for a non-polling solution that can ideally send a notification within around 200ms (seems to be the approximate time taken by other implementations) that doesn't fail under load (we're talking tens of events, not hundreds or thousands).  Your implementation might meet these requirements although I've already looking (briefly) at trz, and couldn't see how I was supposed to integrate it into an application compared with the default "Path" filesystem.
> 
> I'm guessing that your solution might resist the "load" issues I've met with JXFileWatcher, despite the test failure you referred to (which seemed to indicate that the test had defects itself).

Christopher,

I am looking at this again. Picked up where I left off surprisingly quickly. The problem hasn't changed.
Usage for what I'm doing now is something like…
java -cp lib/macnio2.jar -Djava.nio.file.spi.DefaultFileSystemProvider=us.hall.trz.osx.MacFileSystemProvider LotsOfEvents
You may additionally need…
		System.setProperty("mac.watchservice","kqueue");
in your code. I was considering an FSEvent implementation as well for another mac.watchservice.

This is what the code processed on the last test before the first test wait…
LotsOfEvents before repoll num read 22 thread Thread[Test Thread,5,main]
before the first wait. You might or might not have problems with 'tens of events'.

Some of this is based very closely off java source that is not classpath exception. This was necessary because some of the access restrictions seemed to need loosening. It might be 3rd party implementations of WatchServices were not anticipated. I'm not sure what that might imply for serious use regarding licensing. 

I was thinking maybe kqueue and my code both ran off of the main thread so when the code waited the kqueue stopped. But I changed the test to run off a different thread with no improvement. I just changed the wait from a LinkedBlockingDeque poll to a Object wait with the same result. It seems any java wait (at least at this point) causes kqueue to stop posting? Seems strange to me that a random wait on an arbitrary java Thread would halt kqueue.   Anyhow I'm back to thinking about trying a timer callback to avoid the hard wait. Might still get it working somehow.


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




> 
> 
> 
> Thanks,
> Christopher
> 
> 
> On 9 August 2014 02:19, Michael Hall <mik3hall at gmail.com> wrote:
> On Aug 8, 2014, at 5:35 AM, Christopher Brown <christopherbrown06 at gmail.com> wrote:
> 
>> In any case, if there's something to test already, I'm happy to try it out.  If not, it would be helpful to know if it's planned for a specific JDK9 build because current workarounds all have big shortcomings.
> 
> You don't specify what kind of native implementation you are looking for? Just something non-polling?
> Not official for any java but I attempted a kqueue based WatchService on OS X as part of my trz package mentioned below.
> It passed the basic tests included with the nio2 distribution but didn't pass the LotsOfEvents one.
> At some point the test went into a wait to allow the WatchService to process more events. Unfortunately for my implementation when it went into this wait kqueue also went into a wait, processing no more additional events. When that wait timed out, the test failed because it had not processed enough events and hadn't received anymore. Interestingly at that point, after the exception, kqueue resumed pumping events. So the java itself waiting seemed to stop the whole thing. 
> Where I left it as best I remember. Probably pretty messy after one or two attempts to debug. Basic tests might not even pass now.
> I thought about fudging the test to handle the waiting differently but it didn't really seem right that this should be necessary for my implementation.
> 
> I'm more interested in machine learning these days. Kaggle competitions for one thing, a nice level playing field, no fudging needed.
> 
> But maybe if one more person indicated an interest I'd consider that a 'clamor' and get back into this one more time. FSEvents was another possibility as I remember for an implementation I was going to try. Might not have the kqueue problems.
> 
> 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/20140809/43f12241/attachment.html>