kdirwatch vs qfilesystemwatcher

[Andreas Pakulat]

On 06.03.07 12:45:35, Marc Espie wrote:
> On Sat, Mar 03, 2007 at 02:22:59AM +0100, Andreas Pakulat wrote:
> > On 02.03.07 23:30:39, Marc Espie wrote:
> > > While updating the qt4 port for OpenBSD, I noticed the new kqueue support
> > > and activated it.
> > > 
> > > Comparing it for kdirwatch, it is currently grossly inefficient on OpenBSD.
> > > 
> > > I was wondering, what's the difference between kdirwatch and 
> > > qfilesystemwatcher ? In newer qt4, it just looks like qfilesystemwatcher
> > > is doing mostly the same thing in a more efficient way across platforms.
> > 
> > Well, KDirWatch doesn't stop watching files/dirs after they are removed,
> > it only emits 1 signal for dirs or files regardless wether the file/dir
> > changed or is removed..
> > 
> > I hope that either of the two gets heavily extended, for example
> > stopping KDirWatch to watch a specific file (currently it only allows to
> > stop for a dir), watching a dir should emit signals when  a file is
> > created or removed with the filename/dirname not just a dirty signal and
> > the app has to somehow figure out which file/dir was added/removed.
> 
> Well, this doesn't help me much.
> 
> So this is saying that the base kde class is more extensive than what
> qt does, but still this is not enough ?

IMHO: Yes.

> Okay, here's the issue, currently on some `normal' unix systems, KDirWatch
> is responsible for a huge number of stat() calls.

Yes, thats the "last resort" for KDirWatch, when neither a file-monitor
like fam or gamin nor inotify exist in the system.

> On BSD systems, we've
> had kqueue for a while, and Qt4 is finally taking advantage of that.

Well, maybe KDirWatch can be made to work on top of QFileSystemWatcher,
but I don't really know. Somebody with more knowledge about its
internals needs to speak up...

> Before I embark on having a look at KDirWatch and tweaking it to use kqueue
> (or to leverage the base Qt4 class more), I'd like some strong signal that
> this is going to be useful. Like, if the KDirWatch published interface
> changes/gets expanded a lot, I will have to restart the work from
> scratch, which I'd rather avoid...

Well, the ways in which KDirWatch might expand is sending out more
specific signals for directories and I also think a stopFileWatch like
the stopDirWatch would be good. I don't know kqueue but I doubt you'd
have to rewrite the kqueue support from scratch if we add such things...

Andreas

-- 
Is this really happening?