[SpartanJ]

> And on Linux inotify is bound by /proc/sys/fs/inotify/max_user_watches. Six of one, half dozen the other. FreeBSD file descriptor limit is arbitrary and can be raised to INT_MAX (2 billion). That should be plenty.

Yes, on Linux you're limited to max_user_watches, and you can edit that value, just like you say with kqueue... but you need root access, so for end user applications this is not really a solution. With inotify i use one watch per-folder, with kqueue you need to do it by file ( of course you can watch the folder changes, but you need to keep a copy of the file states in that folder, and then re-stat that files to find out what file was changed, not even close to an ideal solution ). So for example in my use case with inotify i can watch 65536 folders, and with kqueue less than 10000 files ( that could be a single folder! ).

Edit: It seems that FreeBSD default a much bigger number for FDs ( https://news.ycombinator.com/item?id=9063893 ), so that should suffice a lot of use cases, that's good news for me!

[throwabob214]

> With inotify i use one watch per-folder, with kqueue you need to do it by file ( of course you can watch the folder changes, but you need to keep a copy of the file states in that folder, and then re-stat that files to find out what file was changed, not even close to an ideal solution ). So for example in my use case with inotify i can watch 65536 folders, and with kqueue less than 10000 files ( that could be a single folder! ).

Ah, I looked at inotify API briefly and did not notice that directory watches return file changes. That does make it easier to use than kevent vnode watches. Mea culpa.