D8043: KDirWatch : make methods virtual

[René J.V. Bertin]

rjvbb added a comment.


  Hmmm, I'll double-check. I didn't really go beyond the thought that it seemed to make sense to use a single watcher instance if most of the time you'll be watching items that live on a single disk.
  
  >   Could it be that QFSW itself uses a single static object internally? In that case it's QSFW that needs to be made threadsafe.
  
  That is certainly a possibility, but "needs"? Not everything in Qt is thread-safe that could be. And even if that is done, wouldn't we want to keep KDW working with Qt versions that will never get the patch?
  
  QFSW doesn't have an API to add a directory recursively, does it? That's the KDW aspect that got me into this can of worms: doing that with even a not-so-big source tree as KDevelop takes a noticeable amount of time, for the GCC source tree it takes around 80 seconds (on a 2.7Ghz i7 Mac). And during that call the calling thread is kept busy, so in KDevelop this simply locks up the UI - for each project to be opened in turn.
  
  The safest and cheapest way I see to avoid this is to add single directories in the thread that also does other things with those directories (building up a project representation, i.e. outside of KDW).
  
  The issues I'm seeing without mutex range from lock-ups to import durations that are increased by varying amounts on Mac; the lock-ups occur in the QFSW FSEvents backend. I haven't yet understood that code (or the FSEvents API) enough, but it's quite possible that there's a single instance of something at that level. On Linux I'm getting occasional double-free crashes. The former happens only when I'm adding lots of items in rapid succession (>=2 threads each importing source trees with hundreds of near-empty directories). I've seen the latter happen for more common source trees.
  
  >   And now that you mention it, I indeed made KDirWatch threadsafe already, at least as far as I could test it on Linux. E.g. KDirWatch::self() is thread-local.
  
  Ah, so that's not a single KDW instance, but one for each thread. That still doesn't mean that you can hand off the instance to a different thread that will add a lot of entries to it.
  
  My initial idea was also that only the QFSW watcher needed mutex protection but as Milian pointed out, there are other things going on when adding an entry that are probably not thread-safe.

REPOSITORY
  R244 KCoreAddons

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

To: rjvbb, #frameworks, mwolff, dfaure
Cc: dhaumann, cfeck, dfaure, mwolff, kde-frameworks-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20170929/0c5ac6c5/attachment.html>