KDirWatcher and dnotify signal problem

Waldo Bastian bastian at kde.org
Mon Sep 2 19:38:56 BST 2002

Hash: SHA1

On Monday 02 September 2002 09:01 am, Lubos Lunak wrote:
>  Hello,
>  could somebody please review the attached patch? The theory is about like
> this: Whoever implemented the dnotify support in KDirWatch simply copied
> the example from kernel documentation. And the example uses SIGRTMIN for
> the signal. And LinuxThreads seem to use SIGRTMIN for its internal purposes
> in some configurations. 

Shouldn't it redefine SIGRTMIN in that case to account for that?

> So since the switch to Qt3 dnotify probably didn't
> work that great.
>  I've found some internal function in glibc for allocating the real-time
> signals and modified KDirWatch to use it. Could somebody review it?
>  BTW, now that the dnotify support finally seems to work, could it be
> enabled by default?

There was (is?) a kernel bug that broke dnotify whenever the process that uses 
dnotify forks and closes the dnotify file-descriptors in the child process. 
(Standard behaviour for KProcess) Has that been fixed already in recent 
kernels? Even then, we should probably detect the kernel version and only use 
it when we know it isn't broken.

- -- 
bastian at kde.org  |   SuSE Labs KDE Developer  |  bastian at suse.com
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org


More information about the kde-core-devel mailing list