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

[René J.V. Bertin]

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:
    <snip> 
    > For calls across threads use QueuedConnection explicitly.. (In most cases
    > Qt detects this automatically, but there are some special cases usually
    > involving moveToThread().)
    <snip>
    > 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.

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D7995

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>