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

[René J.V. Bertin]

rjvbb marked an inline comment as done.
rjvbb added a comment.


  Almost guilty as charged: I tend to confound reentrant and thread-safe.
  You're right of course, if KDW isn't thread-safe itself (and it looks like it probably isn't) there's no getting around using a mutex, but that mutex can still be inside KDW itself.
  
  You probably noticed that I'm using a single mutex like a CriticalSection so that only 1 thread can add entries to any KDW instance in a given session. Initially that was because KDW uses a single QFileSystemWatcher instance behind the scenes, but it might also help avoiding other problems of the kind you evoke. I'm not sure why I didn't do this for the removeDir method too (it's a lot less likely to be called in a highly parallel fashion, of course).
  
  > I mean, what happens when an inotify event comes in - where is that being handled? Who guarantees that this is not going to get run in parallel to code we protect by our own mutex?
  
  I would hope that the dirty and deleted signals are delivered to the thread that connected to them, as Qt promises (I seem to recall :)). In itself that shouldn't be a problem, a change event can also come in while we're adding a directory on the same thread that handles the change events. The existing mutex should kick in if a change event leads to adding a new dir or removing one.

REPOSITORY
  R32 KDevelop

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

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