RFR: 8293067: (fs) Implement WatchService using system library (macOS)

[Brian Burkhalter]

On Tue, 4 Oct 2022 08:07:27 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> On Oct 3\, 2022\, at 4\:34 AM\, Maxim Kartashev \<mkartashev at openjdk\.org\<mailto\:mkartashev at openjdk\.org>> wrote\:
>> 
>> On Mon\, 3 Oct 2022 10\:35\:44 GMT\, Alan Bateman \<alanb at openjdk\.org\<mailto\:alanb at openjdk\.org>> wrote\:
>> 
>> The suggestion was to explore doing this at a low level with kqueue so that we don\'t have callbacks\.
>> 
>> Vladimir Kempik had a draft implementation based on kqueue that\, AFAIR\, passed all the existing tests\; he may be interested in getting his work merged into the mainline\.
>> 
>> As I mentioned\, I wrote a prototype based on kqueue and it also \(usually\) passed all the tests but had problems shutting down\. It also sometimes ran out of file descriptors\. Unless my testing was wrong\, I think that using kqueue here is likely to run into the exhausted file descriptor situation frequently if the \`ENTRY\_MODIFY\` event is watched\. \`ENTRY\_CREATE\` and \`ENTRY\_DELETE\` could be detected by watching the directory file descriptor alone and rescanning the directory\, but modifying a contained file alone will not generate any event on the directory descriptor\, hence watching for \`ENTRY\_MODIFY\` requires an open descriptor for each file in the directory\.
>> \-\-\-\-\-\-\-\-\-\-\-\-\-\- next part \-\-\-\-\-\-\-\-\-\-\-\-\-\-
>> An HTML attachment was scrubbed\.\.\.
>> URL\: \<https\:\/\/mail\.openjdk\.org\/pipermail\/nio\-dev\/attachments\/20221003\/75c87a9b\/attachment\.htm>
>
>>but modifying a contained file alone will not generate any event on the directory descriptor, hence watching for `ENTRY_MODIFY` requires an open descriptor for each file in the directory.
> 
> exactly, the main reason I have dropped that work.

@VladimirKempik Thank you for corroborating my findings.

-------------

PR: https://git.openjdk.org/jdk/pull/10140