lkml.org 
[lkml]   [2004]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:04    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site