https://bugs.kde.org/show_bug.cgi?id=387232
--- Comment #5 from RJVB <rjvber...@gmail.com> --- So... what seems to be burning CPU is a number of FileManagerListJob instances that keep running and calling FileManagerListJob::startNextJob() which in turn emits the watchDir signal. What I fail to see (yet) is how emitting that signal can lead to this. Adding a directory to the watch list doesn't have the direct effect of (re)loading that directory, and there are no dirty signals being generated either (those could of course cause directory reloading). Yet, the issue goes away when I make ProjectWatcher::addDir() a stub (that doesn't call KDirWatch::addDir()). I could imagine how the autoconf and configure steps generate one or more directories that should be ignored, but not how the current "stock" dirwatching implementation isn't vulnerable to this situation. The whole issue went away when I undid the configure.ac edit, restored the original configure file and re-ran my configure command OUTSIDE of KDevelop. Only to start anew as soon as I made a change to configure.ac in KDevelop, before I even saved the file. I'm going to see what happens when I emit the dirWatch signal only for previously unwatched directories or from a different location, but I think the issue goes deeper than just my new dirwatching algorithm. It looks to me that there's an issue with the project manager being used here which is exposed/triggered by my dirwatching algorithm. -- You are receiving this mail because: You are watching all bug changes.
