OS X watch service

[Michael Hall]

If of interest, maybe if someone else gets to looking at a kqueue based watch service later.

It is seeming not very well suited to the LotsOfEvents test, or very scalable more generally due to it’s requirement of an open fd for every monitored file. 
Possibly opening the files O_EVTONLY gets around this. It’s not entirely clear to me if this does avoid the open fd limit.
What it appears to be doing now is filling up the kqueue event list and then stop processing.
From the source the event list size appears to be…
#define NEVENT		64
The closest I seem to get to this is about 63.
Then kqueue then stops processing events, until the LotsOfEvents test starts deleting files, this probably results in the fd’s getting closed.
Then kqueue resumes posting. 
I’m not sure if this is a bug in mine or kqueue, or expected behavior, not a bug, who knows. Again, like deadlocks, I haven’t been able to turn up much on the kqueue list filling up in searching.
Mine is based on existing and I assume working code. The original didn’t recurse directories and add those in like mine does. Or actually I don’t think it handled a directory WRITE event which amounts to a file create in the directory.
Anyhow, for now I’m just thinking kqueue isn’t very well suited to this sort of processing and am considering implementing something else for monitored directories. 
Maybe fsevents or dispatch sources. Possibly allowing the user to configure a little with system properties. These api’s are at the directory level and are not granular to individual files. So I will need PollingWatchService type code to determine what has actually happened at that level. If PollingWatchService could wake up on a notification it would probably be fine for the purpose. Given it can’t be, I will probably duplicate some of the functionality in native.

I would be interested in seeing if a jdk implementation does do better with kqueue at some point.

Michael Hall