Re: [patch] signal handler defaulting fix ...

[Edgar Toernig]

Linus Torvalds wrote:
> 
> On Mon, 28 Jun 2004, Davide Libenzi wrote:
> > 
> > It's not that the program try to block the signal. It's the kernel that 
> > during the delivery disables the signal. Then when the signal handler 
> > longjmp(), the signal remains disabled. The next time the signal is raised 
> > again, the kernel does not honor the existing handler, but it reset to 
> > SIG_DFL.
> 
> So? That program is buggy.

Not the signal part.  It was written for libc5.  There, signals set
with signal(2) were reset when raised (SysV-style).  Leaving such a
signal handler with longjmp was perfectly valid.

Glibc2 changed the rules: signals set with signal(2) are not reset
but blocked during delivery (BSD-style).  It worked for a while
because the kernel ignored the sigmask for some signals.

So, if one is to blame then glibc2 by breaking compatibility.

With Davide's patch the kernel would be a little bit more tolerant to
old code by keeping the 2.4 behaviour.  The current strict behaviour
becomes OK when signal(2) is no longer part of glibc...

Ciao, ET.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/