I created an account over here to hopefully help with the dialog.
From my assessment, using kqueue to monitor for file changes requires opening the fd for every file and directory contained within the directory tree. I've contacted a few Plex users to ask the size of these library as well as the amount of RAM they have to better assess the feasibility. One example I obtained the user has over 500,000 files and directories with 16G of RAM. If he were on FreeBSD (not Windows) and a kqueue-based file change monitoring was done with his library, the process would exceed the limit of the maximum number of open files. Several others come close to the limit and this is among a sample of about 10 users I've personally asked. There are several "build threads" in Plex's forums that tell you they would either come close or exceed the limit as well. Add to this that Plex has recently added support for photo libraries and many of Plex's users are avid or professional photographers, it is easy to see how these directory trees can grow to be enormous in terms of file count. Given how detrimental hitting these limits would be to the application as a whole, this would also require reading the limit as well as a scan to see if the limit is in danger of being hit before enabling the function. Furthermore, if enabled, the count would need to be monitored to disable it if the library were to grow dramatically (such as first-run setup adding all the libraries) and be again in danger of hitting the limit.
On the practice of using kqueue: When using kqueue, the code is not told a path for the change but rather the fd. This means the application must keep a mapping from fd -> path. Furthermore, the information about the change is somewhat limited, meaning that if the fd corresponds to a directory, that directory must nearly always be rescanned. This means there must be a mapping from path -> fd to determine if a file/directory within the scanned directory is already monitored or not. (In reality these maps would be to a common data structure rather than just path <-> fd.) This is a large amount of accounting that must be done by the application. So large in fact that an initial stab at implementing this monitoring for FreeBSD produced code about as large as the monitoring for MacOS, Linux, and Windows combined (as well as including the common functions used across all platforms). Some of this can be saved by using `udata` inside `kevent` but at most that would be one map and very few lines of code.
On the philosophy of using kqueue for FS monitoring: I see how kqueue has great purposes, but it strikes me as its intent was to monitor sockets more so that files. Extending this use to directories/files seems to me like a bit of a hack, but I suppose it works well enough for a small set. When it is scaled to such a large number as would be used in several users' Plex libraries, it looks far more like it is being used for a task it was never designed to handle. Even more so when these libraries are mostly quiescent with occasional additions/subtractions/modifications of files/directories. Holding hundreds of thousands of fds open for what is likely a 10s of changes a day seems excessive. It strikes me that FreeBSD really needs some kernel API that's truly designed for file system monitoring over using an existing API that seems ill-suited for this scale.
On inotify: Personally, I'd prefer FSEvents over inotify as inotify still requires opening an fd-like object for every directory. It does give information about changes to files contained within the directory though and provides path information on the changed item. This does reduce the amount of accounting the application must perform but there's still some for every directory. The FSEvents monitors an entire directory tree at once and provides rich information in its callback. This is much easier on the developer.
. Plex devs seem to think kqueue just won't work and can't/won't implement support for it.
