KDirWatcher and dnotify signal problem
trouble at garni.ch
Thu Sep 5 12:24:47 BST 2002
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)
> > > 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
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.
More information about the kde-core-devel