Review Request 124128: KDirWatch: Only establish a connection to FAM if requested

David Faure faure at kde.org
Fri Jun 26 07:59:23 UTC 2015


-----------------------------------------------------------
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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150626/5d957c0e/attachment-0001.html>


More information about the Kde-frameworks-devel mailing list