KDirWatcher and dnotify signal problem
l.lunak at sh.cvut.cz
Thu Sep 5 14:33:08 BST 2002
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
> > > > 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
> 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).
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/
More information about the kde-core-devel