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

[Christopher Brown]

If there are licencing issues, maybe a standalone watcher would be enough?
Looking at the command line you used, I get the impression that you had to
reimplement a significant par of the API (Paths and stuff) for this service
(and other Mac-specific stuff).


On 9 August 2014 22:21, Michael Hall <mik3hall at gmail.com> wrote:

> 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/5dce258c/attachment-0001.html>