[lkml]   [2004]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] signal handler defaulting fix ...
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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:04    [W:0.040 / U:67.104 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site