• Elias Naur's avatar
    runtime: don't always unblock all signals · 84cfba17
    Elias Naur authored
    Ian proposed an improved way of handling signals masks in Go, motivated
    by a problem where the Android java runtime expects certain signals to
    be blocked for all JVM threads. Discussion here
    
    https://groups.google.com/forum/#!topic/golang-dev/_TSCkQHJt6g
    
    Ian's text is used in the following:
    
    A Go program always needs to have the synchronous signals enabled.
    These are the signals for which _SigPanic is set in sigtable, namely
    SIGSEGV, SIGBUS, SIGFPE.
    
    A Go program that uses the os/signal package, and calls signal.Notify,
    needs to have at least one thread which is not blocking that signal,
    but it doesn't matter much which one.
    
    Unix programs do not change signal mask across execve.  They inherit
    signal masks across fork.  The shell uses this fact to some extent;
    for example, the job control signals (SIGTTIN, SIGTTOU, SIGTSTP) are
    blocked for commands run due to backquote quoting or $().
    
    Our current position on signal masks was not thought out.  We wandered
    into step by step, e.g., http://golang.org/cl/7323067 .
    
    This CL does the following:
    
    Introduce a new platform hook, msigsave, that saves the signal mask of
    the current thread to m.sigsave.
    
    Call msigsave from needm and newm.
    
    In minit grab set up the signal mask from m.sigsave and unblock the
    essential synchronous signals, and SIGILL, SIGTRAP, SIGPROF, SIGSTKFLT
    (for systems that have it).
    
    In unminit, restore the signal mask from m.sigsave.
    
    The first time that os/signal.Notify is called, start a new thread whose
    only purpose is to update its signal mask to make sure signals for
    signal.Notify are unblocked on at least one thread.
    
    The effect on Go programs will be that if they are invoked with some
    non-synchronous signals blocked, those signals will normally be
    ignored.  Previously, those signals would mostly be ignored.  A change
    in behaviour will occur for programs started with any of these signals
    blocked, if they receive the signal: SIGHUP, SIGINT, SIGQUIT, SIGABRT,
    SIGTERM.  Previously those signals would always cause a crash (unless
    using the os/signal package); with this change, they will be ignored
    if the program is started with the signal blocked (and does not use
    the os/signal package).
    
    ./all.bash completes successfully on linux/amd64.
    
    OpenBSD is missing the implementation.
    
    Change-Id: I188098ba7eb85eae4c14861269cc466f2aa40e8c
    Reviewed-on: https://go-review.googlesource.com/10173Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
    84cfba17
signal_darwin.go 2.58 KB