[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.022 / U:30.344 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site