[kde-freebsd] FAM issue.

[Markus Brüffer]

Pawel Wieczorek schrieb:
> I am interrested to help your with porting KDE, now I am waiting
> for end of compilation. After that i will want to try some small problems at 
> fist.

Cool! Although I don't believe that this problem qualifies as "small" as it 
will be quite some work, I think.

> The FAM issue on KDELIBS looks to be good point for start, could
> someone tell more about problem ?

KDE has some sort of superdaemon (similar to inetd) that is responsible for 
several services. It's called kded4 (or kded in KDE 3.x). One of the 
services is a directory watcher that notifies applications if the contents 
of a directory have changed (e.g. dolphin).

This directory watcher is implemented as class KDirWatch as plugin for kded4:

Small Tutorial:
http://techbase.kde.org/Development/Tutorials/Programming_Tutorial_KDE_4/KDirWatch

API documentation:
http://api.kde.org/4.0-api/kdelibs-apidocs/kio/html/classKDirWatch.html

Source:
kio/kio/kdirwatch.{c,h} in kdelibs

It has several backends for the different operating systems (polling as 
easiest but worst one, inotify, etc). One of the backends is FAM, a cross 
platform file alteration monitor, which currently doesn't work correctly. 
Worse, it affects the behaviour of kded4 and as such KDE4 as a whole and 
causes many strange effects. It looks like kdirwatch and FAM are deadlocking 
and when terminating KDE4, kded4 isn't terminated as a further result.

ktrace (or if you are using -CURRENT you can try out dtrace) is useful for 
debugging this as you can have a look at the socket communication that takes 
place.

Regarding FAM: We currently have 2 API/ABI compatible FAM implementations: 
FAM itself (devel/fam) and gamin (devel/gamin). Currently we use gamin as it 
has some advantages over FAM. One of it is that the FAM server process 
(gam_server for gamin) doesn't have to be set up manually using inetd. It is 
spawned automatically.  This makes debugging a bit more difficult, though, 
as kded4 is started somewhere in the startup scripts of kde4, which in turn 
starts up gam_server.

By ktrace'ing the parent kdeinit process one is able to obtain all 
information, but one get's a lot more that that. I had to modify ktrace to 
accept multiple "-p" arguments to see the interaction of kded4 and 
gam_server side by side.

I didn't have enough spare time so far to track it down, but if you have any 
questions, just shout.

Thanks,

Markus