Re: [linux] Always ignore restart/cancellation signals

[Mark Kettenis <mark dot kettenis at xs4all dot nl>]

> Date: Fri, 9 Dec 2005 13:58:10 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Fri, Dec 09, 2005 at 08:51:23PM +0200, Eli Zaretskii wrote:
> > > Date: Fri, 9 Dec 2005 09:46:51 -0500
> > > From: Daniel Jacobowitz <drow@false.org>
> > > 
> > > On Fri, Dec 09, 2005 at 04:44:16PM +0200, Eli Zaretskii wrote:
> > > > > Date: Fri, 9 Dec 2005 09:34:52 -0500
> > > > > From: Daniel Jacobowitz <drow@false.org>
> > > > > 
> > > > > The problem is that an application may want to register handlers for "a
> > > > > few" realtime signals.  It seems common to count up from SIGRTMIN, so
> > > > > SIGRTMIN is made a runtime constant that skips those signals belonging
> > > > > to the implementation.
> > > > 
> > > > Does this mean that ``constants aren't'', like the old joke says?
> > > 
> > > Precisely!  Directly above the bit Kevin quoted:
> > > 
> > > #define SIGRTMIN        (__libc_current_sigrtmin ())
> > > #define SIGRTMAX        (__libc_current_sigrtmax ())
> > 
> > Then we should probably use these instead.
> 
> No, we shouldn't.  Let me try the explanation over from the top.
> 
> The thread library reserves some realtime signals to itself.  These are
> specifically those between __SIGRTMIN (a constant) and SIGRTMIN (a
> function call).  A well-behaved application should not manually
> generate those signals nor attempt to handle them.
> 
> But GDB isn't trying to use realtime signals.  It's trying to find the
> signals used by the inferior's threading implementation, so that it can
> transparently ignore them, instead of stopping the application by
> default every time that a thread is cancelled (or, for LinuxThreads,
> every time a thread blocked on a mutex is woken!).
> 
> If the thread library is kind enough to tell us which signals it is
> using, then we use those numbers.  If it isn't, we must guess.  The
> only correct guess is __SIGRTMIN (32 on all Linux systems, and this is
> Linux-specific code...) and __SIGRTMIN+1.  SIGRTMIN is generally 34 or
> 35, and would be the right choice for GDB to use in sending its own
> signals to itself.

Ah yes, it all comes back to me.  Believe SIGRTMIN will be 32, unless
you link your stuff with libpthreads, since that consumes two signals
for internal use, and therefore SIGRTMIN will be 34.  Are the signal
numbers hardcoded in libpthread (in particular the NPTL one) or does
it depend on whether there are other consumers of real-time signals?

Mark