On Fri, Jun 15, 2012 at 3:57 PM, Alberto Villa <avi...@freebsd.org> wrote:
> On Friday 15 June 2012 12:48:48 Oleg Sidorkin wrote: > > Original fix is a workaround of QT behavior on MacOS - as far as I > > understand Linux is able to monitor files without opening them using > > inotify. FreeBSD has no similar functions so QT has to open each file to > > monitor it. > > Yes. inotify monitors file names, kqueue monitors file descriptors. > > Can you spot differences in file monitoring after you've applied your > patch, > anyway (maybe move some pictures away to let it start with the original > code)? > Due to differences in KDirWatch implementations, there is a chance that the > final behaviour doesn't change (kqueue is able to detect modifications to > files when monitoring a directory). In fact, it looks like code previous to > the commit that triggered the bug was monitoring only directories, so the > patch should have no effects apart from reduced efficiency. > > Anyway there is something I don't understand. I spent some time reading > KDirWatch code, and FAM is used by default on FreeBSD. Now, FAM uses > Gamin, and Gamin says: > > Gamin will only provide realtime notification of changes for at most n > files, > where n is the minimum value between (kern.maxfiles * 0.7) and > (kern.maxfilesperproc - 200). Beyond that limit, files will be polled. > > Why is digiKam failing and not just polling transparently? Is it (or most > likely KDE-Libs) using QFileSystemWatcher instead (which uses plain kqueue > without falling back to polling, if I remember correctly)? > -- > Alberto Villa, FreeBSD committer <avi...@freebsd.org> > http://people.FreeBSD.org/~avilla > > It is hard to predict, in particular about the future. > -- Robert Storm Petersen > I'll test the monitor behavior this weekend. Thanks -- Oleg Sidorkin
_______________________________________________ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information
