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    [W:0.022 / U:0.152 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site