----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124128/#review81768 -----------------------------------------------------------
The logic "if inotify is available then we don't need FAM" is wrong. Even if it's going to use inotify for most things, as soon as you try watching a file on an NFS mount, you need FAM. This is why the code has a *list* of available methods, and goes through them for every watched dir (stopping at the first one that works). However I like your idea of avoiding FAMOpen if not necessary, it just means FAMOpen should be called on demand, the first time we actually try to use FAM to watch something. AFAICS the qfilesystemwatcher code path works like that. - David Faure On June 19, 2015, 5:04 p.m., Vishesh Handa wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124128/ > ----------------------------------------------------------- > > (Updated June 19, 2015, 5:04 p.m.) > > > Review request for KDE Frameworks and David Edmundson. > > > Repository: kcoreaddons > > > Description > ------- > > KDirWatch by default initializes a connection to both inotify and FAM, > even if we aren't going to be using either. This is unnecessary and the > FAM backend has caused it to block for a while on running FAMOpen. > > > Diffs > ----- > > src/lib/io/kdirwatch.cpp 246be82929cc08e40bd9eceec017036ec4686c26 > > Diff: https://git.reviewboard.kde.org/r/124128/diff/ > > > Testing > ------- > > Unit tests pass > > > Thanks, > > Vishesh Handa > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
