KDirWatcher and dnotify signal problem

[Lubos Lunak]

On Thursday 05 September 2002 13:24, Jörg Walter wrote:
> On Tuesday 03 September 2002 20:01, Josef Weidendorfer wrote:
> > On Monday 02 September 2002 20:38, Waldo Bastian wrote:
> > > [...]
> > > Shouldn't it redefine SIGRTMIN in that case to account for that?
> >
> > Probably right, as the includes come from GLIBC and not from the kernel,
> > as it was in the past. But the include file has to know that you link
> > with -lpthread, and that's something only the linker knows.
>
> Not entirely correct - you get _REENTRANT defined if you use threads.
> linking with libpthread but compiling w/o _REENTRANT would not work, since
> the standard header files use it to replace some thread-unsafe stuff with
> thread-safe, but possibly slower variants (errno, for example)

 Actually, with glibc-2.2, _REENTRANT doesn't make any difference when 
compiling, besides adding some *_r() functions. But it doesn't really matter 
here.

>
> > > > So since the switch to Qt3 dnotify probably didn't
> > > > work that great.
> >
> > I don't think the RTMIN was the problem; it was the LINUX kernel bug.
> > I think the PThread library won't do anything with RTMIN until
> > multithreading is actually used in the app. And how many apps in KDE 3
> > really use multithreading?
>
> Every app, when you use the liquid style. (At least I think I read
> something about multithreaded animation...)
>
> Quote from signal(7):
>
> Unlike standard signals, real-time signals have no predefined meanings: the
> entire set of real-time signals can be used for application-defined
> purposes. (Note, however, that the LinuxThreads implementation uses the
> first three real-time signals.)
>

 There are actually two problems:

- LinuxThreads takes care of changing SIGRTMIN etc. in case you use it, but 
only if the application itself links against -lpthread too. If the app only 
links against a library that links against -lpthread, symbols from -lpthread 
replacing those libc ones aren't used (libpthread needs this kind of special 
treatment, I'm not exactly sure why). But libtool takes care of this, this 
only confused me when I tried with small test apps, so this is not a real 
problem for KDE.

- LinuxThreads seems to block signal 32 (==real SIGRTMIN) for all its 
children, because it uses it internally. Non-threaded apps (or those linking 
to apps linked to -lpthread but not the app itself linked with -lpthread) 
will have their SIGRTMIN really 32, and thereforce won't work under KDE 
(because they will be children of kdeinit etc., and signal 32 will be 
blocked). App linked against -lpthread will have SIGRTMIN changed to 35.

 So in fact there's no real problem for KDE, the original problem I tried to 
solve was in the application (and only these things listed above made it 
confusing). 

> To be clean&safe, it should use SIGRTMIN+3 (or some higher number, up to
> SIGRTMAX( == SIGRTMIN+31 usually)) instead of SIGRTMIN, a change that is
> unproblematic for the non-threaded case, so there is no need to distinguish
> the threaded and the untreaded case.

 However, we should probably do something with the signal used. We're a 
library and when just hardcoding SIGRTMIN this may clash with other piece of 
code using SIGRTMIN. My original patch uses __libc_allocate_rtsig(), which is 
not documented, and doesn't help much if somebody else hardcodes SIGRTMIN 
anyway. I suggest we simply change SIGRTMIN to e.g. (SIGRTMIN+15).


-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/