On Sat, Jan 01, 2011 at 03:34:27PM +0100, Andreas Vögele wrote: > 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
That's the name of default watcher, the `Default', yeah? Confusing.. > 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. Because IO::KQueue to work reliably makes the user to modify login class capabilities and system resources personally I think lack of dependency in p5-File-ChangeNotify on p5-IO-KQueue is good idea. I don't have anything against what is currently in p5-File-ChangeNotify port in terms of dependencies on IO::KQueue[ref#1]. > > 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. What means "the KQueue-based watcher will fail" in above context? Will IO::KQueue croak/die if it hit resource limit and File::ChangeNotify currently doesn't handle when one watcher fails to switch to another one[ref#2]? > > 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. As wrote above[ref#1], that makes sense for me to not force user to use IO::KQueue (but use it when is makes sense -- when IO::KQueue is installed and properly configured -- read sysctl.conf and login.conf limits bumped). > 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. So, File::ChangeNotify doesn't handle resource limits gracefuly, yeah[ref#2]? If that is true, your changes make sense for me. -- best regards q#
