[PATCH] D58418: [clang][DirectoryWatcher] Upstream DirectoryWatcher

Michał Górny via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sat Feb 23 11:01:26 PST 2019


mgorny added inline comments.


================
Comment at: clang/lib/DirectoryWatcher/DirectoryWatcher-linux.inc.h:135
+        if (!statusOpt.hasValue())
+          K = DirectoryWatcher::EventKind::Removed;
+      }
----------------
akyrtzi wrote:
> mgorny wrote:
> > jkorous wrote:
> > > mgorny wrote:
> > > > Why? I suppose this deserves a comment.
> > > I'll add this comment:
> > > 
> > > // The file might have been removed just after we received the event.
> > Wouldn't that cause removals to be reported twice?
> Not quite sure if it can happen in practice but I'd suggest to accept this as potential occurrence and add it to documentation ("a 'removed' event may be reported twice). I think it is better to handle a definite "fact" (the file doesn't exist) than ignore it and assume the 'removed' event will eventually show up, or try to eliminate the double reporting which would over-complicate the implementation.
> 
> After all, if inotify() is not 100% reliable then there's already the possibility that you'll get a 'removed' event for a file that was not reported as 'added' before.
I see this as a partial workaround for race condition. You 'fix' it if removal happens between inotify reporting the event and you returning it. You don't if removal happens after you push it to events. Therefore, the caller still needs to account for 'added' event being obsolete. I don't really see a purpose in trying to workaround the problem partially here if the caller still needs to account for it. Effectively, you're replacing one normal case and one corner case with one normal case and two corner cases.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58418/new/

https://reviews.llvm.org/D58418





More information about the cfe-commits mailing list