OS X watch service

[Michael Hall]

I think I raised some of this long ago but I am looking at it again and it is sort of related to the PollingWatchService discussion that just came up on the list. As far as I know OS X is about the only platform using PollingWatchService. So I will raise the issue again.

I had tried to write a native OS X watch service based on UKKQueue.[1] I got this to where it would pass the nio.2 Basic tests but did not pass the LotsOfEvents test.
The issue was that when the test went into a wait for more events kqueue for some reason would stop posting them. It seemed some sort of deadlock which my native programming skills were not up to resolving. Eventually I left the project at that being unable to correct this.

I did leave the code on github, with ’trz'  my OS X nio.2 filesystem related code,  as shown at [2]. Someone recently forked it and indicated on their fork that LotsOfEvents worked. Unfortunately it appears I left the test code in a state where it appeared to work when actually it did not. But this did get me looking at the code again.

I had considered updating my version of the code with VDKQueue[3] an updated version of UKKQueue that is partly based on GCD, grand central dispatch. I just began doing this but looking at it it seemed that the only part that used GCD was the part that did notification of filesystem changes. I wasn’t sure this would correct the deadlock issues I was seeing. So this morning I just tried to change 
my version to use GCD for async notifications like…

								dispatch_async(dispatch_get_main_queue(),^{
									[self postJava:context about:FILE_MODIFIED withWatchKey:watchKey];
								}); 

This didn’t in fact correct the problem. It did run as before but seemed to hang on completion not allowing clean shutdown.

The next thing I am considering is going all GCD with something based on Dispatch Sources[4]. In looking for examples of it’s use though I am not seeing any that work like mine where if you are monitoring a directory you separately add an open fd for each file in the directory. They usually appear to have only one open fd. Some do seem to do directory sweeps on an event to determine what has changed. Like PollingWatchService.This might be seen as better in requiring fewer open fd’s avoiding possible limitations.  Again, there is no guarantee this avoids the deadlock issue but it is a more
non-threaded approach. 

The other approach I had considered back when I had issues with my kqueue implementation was in fact a simpler approach something like this. On receiving an event, the native code could post this to something like PollingWatchService that would wake up, sweep the directory and see what had changed. Or maybe you could post it with a filename as well and it could go from there. However, PollingWatchService seemed difficult if not impossible to subclass and I never got around to writing a modified version.

So, I guess I am, at this point,  simply throwing this out for any suggestions, concerns, thoughts - these would be appreciated. One reason I didn’t keep going before is there really didn’t seem to be that much interest. So just indicating that would be good in making it seem worth the effort. 

[1] http://www.zathras.de/angelweb/sourcecode.htm
[2] https://github.com/mik3hall/trz <https://github.com/mik3hall/trz>
[3] https://github.com/bdkjones/VDKQueue <https://github.com/bdkjones/VDKQueue>
[4] https://developer.apple.com/library/content/documentation/General/Conceptual/ConcurrencyProgrammingGuide/GCDWorkQueues/GCDWorkQueues.html#//apple_ref/doc/uid/TP40008091-CH103-SW22 <https://developer.apple.com/library/content/documentation/General/Conceptual/ConcurrencyProgrammingGuide/GCDWorkQueues/GCDWorkQueues.html#//apple_ref/doc/uid/TP40008091-CH103-SW22>


Michael Hall



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20161210/2e82ce9d/attachment-0001.html>