Mikolaj Kucharski writes: > On Sat, Jan 01, 2011 at 01:23:12PM +0100, Andreas Vögele wrote: >> It seems that the port so far didn't take into account that the >> p5-IO-KQueue package could be installed on the system. Since the >> KQueue-based file watcher quickly exceeds the maximum number of >> open files in a default OpenBSD installation, I changed >> ChangeNotify.pm to prefer the Default watcher even if IO::KQueue is >> available. I think this is more reasonable than to ask the users to >> raise their openfiles and maxfiles limits from 128 and 7030 to much >> higher values. > > Ok. What about users, who altered their system already, and have > raised kern.maxfiles and openfiles-cur in login.conf(5) for example, > for gam_server (see gamin package). > > Not that I am using ChangeNotify.pm, but what is default watcher in > that module?
The default is the Default watcher unless you have happened to install the p5-IO-KQueue package, which the current p5-File-ChangeNotify package does NOT depend on. If anybody uses p5-File-ChangeNotify _with_ p5-IO-KQueue _and_ has raised the resource limits that person should have complained a long time ago about the missing dependency on p5-IO-KQueue. > Which watcher is more efficient? Does your change (to not use > IO::KQueue as default watcher) help the user of ChangeNotify.pm in > any way? In my opinion robustness is more important than efficiency. The ports and packages are supposed to make life simple for the users. If the KQueue-based watcher becomes the default, most users who install p5-File-ChangeNotify - very likely because of a dependency - will have to raise their resource limits. The default for the openfiles resource limit is 128, which means that the KQueue-based watcher will fail on any directory that contains more than 127 files. The Default watcher on the other hand is slower but can handle large directories without any modification to the system's configuration. > As wrote above, I'm not using module in subject, but I have concerns > for changing defaults.. I'm asking as I feel I'm missing something to > understand reasoning. I doubt that the defaults are changed for anybody. On the contrary, so far the port doesn't depend on p5-IO-KQueue, which suggests that whoever created this port didn't consider the KQueue-based watcher. Actually, if the p5-IO-KQueue package is installed the regression tests of the current port fail because of a bug in KQueue.pm. My guess is that the port was merely created to satisfy dependencies. Also, if p5-IO-KQueue is pulled in by some other package, the current p5-File-ChangeNotify package might suddenly start to fail because the installation of p5-IO-KQueue changes the default from the Default watcher to the KQueue watcher. This is not what users expect. Furthermore, it's not possible to automatically decide at runtime whether to use the Default or the KQueue watcher. When the watcher is instantiated the size of the directory is not known. Also, directories might grow during runtime. Using the KQueue-based watcher is dangerous unless you know for sure that the size of the watched directories will never exceed your resource limits. A hybrid watcher that tries to use KQueue and falls back to the Default mechanism if a threshold of available file descriptors is reached could make sense though. But my goal is just to get this port updated so that eventually Moose can be updated.
