KDirWatcher and dnotify signal problem

[Jörg Walter]

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 
real-time signals.) 

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.

CU
Jörg