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

[Christopher Brown]

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).

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