On Sunday December 03 2017 12:01:12 David Faure wrote: > How many calls to addDir() are we talking about?
That's the main point: potentially lots. The function that loads directories and also sets the watch will also be called when a KDirWatch::dirty signal is received, plus when the user triggers a manual reload. Refcounting is simply pointless here as far as I'm concerned. > I disagree. I find it more elegant for an app to know what it's doing. > Whatever > else it's doing when "loading a directory" might also need to know that it > already did that before, no? Clearing previous data structures, whatever. In other situations I might agree. Here not so much given what I'm working with and that I want to limit the foot-print of my changes to existing code. Adding a tiny watcher class that inherits KDirWatch allows me to do that while still do all what little extra stuff I find important or prudent (like turning off the watcher after the aboutToQuit signal). > Which is exactly why refcounting exists. If those other parts of the code > need to stop watching for some reason (other than dir deletion!), > then you still want your "directory loader" to keep watching. No, I don't think so in this case. We're not dealing with a single app-wide dirwatching instance here, but as I said, I still have to look into if and how the export is actually used. > All KDirWatch backends do the same, they remember "it was deleted" > and are ready to notify again if it reappears. Keeping a resource allocated which could be used for something more useful. "It reappearing" will also be signalled as a change in the parent directory, after all. > This is about KDevelop iirc? How many times do people delete entire > directories in kdevelop? Whether they do it in KDevelop or in a terminal with the project open doesn't really matter, does it? How many times do people do things that might lead to directories being deleted, like switching out different VCS branches? Or run autoconf/configure or make (clean) in projects configured for in-tree building? > Is one dormant entry in KDirWatch really worth all > this trouble? IIRC *BSD kernels will allow 256 open filedescriptors, and if my observations from KDE4 days are still valid in this area, each watch consumes 2 file descriptors with BSD-like monitoring functionality. Apple's FSEvents framework (which backs QFSW on Mac) also should be used with some consideration. It may indeed not be very much worth the trouble dragging on this conversation, though :) > I was rather expecting that the use case for removeDir would be closing a > project though. Actually, KDevelop has always removed the watches from items being removed as far as I can tell. What's new is the watching of only directories, and setting those watches as part of the project directory traversal that has to be done anyway. The initial (current stock) implementation does a single call to KDW::addDir() telling it to add all files and directories recursively. That can take a (really) long time for big projects (like gcc's source tree) when not using INotify, a time during which the entire UI is locked. To top that off, the result is unreliable to completely dysfunctional dirwatching on Mac (the FSEvents backend can only watch directories from what I understood). Most of those issues disappear with my approach, it just gets a bit stressed when doing things like running an in-tree configure which lead to incessant on-disk changes. R.
