D7995: KDevelop: address dirwatching inefficiency (WIP/PoC)

René J.V. Bertin noreply at phabricator.kde.org
Thu Nov 16 13:20:16 UTC 2017

rjvbb added a comment.

  Milian Wolff wrote on 20171116::12:22:21 re: "https://phabricator.kde.org/D7995: KDevelop: address dirwatching inefficiency (WIP/PoC)"
  >   I won't accept it with traces of useless stuff in it.
  And I won't have my name associated with something that's not to par with my own standards. At the very least I'll have to remove my (C) notice.
  >   Unclear behavior? That needs to be fixed in KDirWatch upstream then.
  The unclearness yes, but it's not up to us to decide whether KDW::addDir() should ignore duplicates or keep some kind of internal track as it appears to be doing.
  The proposed improvement adds the directory to the watched list each time that directory is loaded and reloaded. That's unnecessary and that should be enough reason to verify if a directory is already watched before handing it off to KDW::addDir(), and one logical place to do that is in ProjectWatcher .
  >   FUD. I'm a Qt dev, and I told you how it works which should be reliable for your purpose here.
  That has turned out not to be the case, I already told you I've seen deadlock-like situations.
  Citing Konrad Rosenbaum from the development ML:
    > With Qt there are some simple rules:
    > For calls across threads use QueuedConnection explicitly.. (In most cases
    > Qt detects this automatically, but there are some special cases usually
    > involving moveToThread().)
    > Do not make any assumptions about the order of signals or slots. Try to
    > avoid the assumption that a signal only returns after the slot has been
    > executed (or that it returns immediately) - you'll mess with connection
    > settings soon enough after you forgot that you rely on it. Regard signals
    > as fire-and-forget-but-maybe-take-some-time-with-unknown-effects.
    > The combination of these will ensure that your application behaves in an
    > acceptable manner.
  That's not FUD, that's common sensical defensive programming (taking the form of "let's add a flag that normally should be added automatically"). I frankly don't understand why we're even having this discussion.

  R32 KDevelop


To: rjvbb, #kdevelop, mwolff
Cc: aaronpuchert, arrowdodger, kfunk, dfaure, mwolff, brauch, kdevelop-devel, njensen, geetamc, Pilzschaf, akshaydeo, surgenight
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20171116/7456270c/attachment.html>

More information about the KDevelop-devel mailing list