[lkml]   [2003]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Never mind. Re: Signal left blocked after signal handler.
    On Thu, 2003-11-27 at 04:11, Ingo Oeser wrote:
    > On Wednesday 26 November 2003 22:53, Albert Cahalan wrote:

    > [2.4 vs. 2.6 wrt. thread synchronous signals]
    > > How about making the process sleep in a killable state?
    > >
    > > This is as if the blocking was obeyed, but doesn't
    > > burn CPU time. Only a debugger should be able to
    > > tell the difference.
    > This has 2 problems:
    > 1) Servers and PID files or servers and simple monitoring software.
    > 2) Processes spawned from init, which will not respawn.

    It has benefits:

    1. Continuous respawning is no good.
    2. If the processes sleeps, you can attach a debugger.

    The obviously correct behavior is to go back into
    user space, likely to take the signal again. The only
    thing wrong with this is that it eats CPU time.
    So _pretend_ to do that. Have the process sleep,
    ideally with an "R" state as seen in /proc, and maybe
    even go back to the crazy loop if someone attaches a

    The crazy loop is most correct though. It's what the
    user asked for. It perfectly handles the case of a
    repeating SIGFPE (blocked) followed by some other
    thread unmapping a page of instructions or data that
    turns the SIGFPE into a SIGSEGV.

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