os/signal: document signal behavior

[ianlancetaylor]

Right now at process start up time on a Unix system all signals are caught, except that if SIGHUP and SIGINT are ignored, they remain ignored. If the program uses the os/signal.Notify to request notification of a signal, and then calls Stop, the signal will no longer be caught--it will revert to the default behaviour.

There are three states for a signal: caught, default, ignored. Right now we always start at caught, except for SIGHUP/SIGINT, and then os/signal can change to default. We should be more consistent about signal states. Or at least document it better.

[alexbrainman]

There are three states for a signal: caught, default, ignored. ...

Not on windows. Windows Ctrl+C cannot be ignored. By default Windows provides its own handler (print ^C and exit process), but you can override it with SetConsoleCtrlHandler. Of course you can provide your own Ctrl+C handler that does nothing.

Alex

[ianlancetaylor]

Thanks. I was perhaps less clear than I should have been that this issue is Unix-specific.

[alexbrainman]

Maybe this functionality should not be part of os/signal then. (I am not sure what happens on plan9). At the very least, we should be clear about this in the documentation.

[rsc]

We need to document signal states but also other details. For example, what happens if C registers a signal handler and then Go does? What happens in the reverse order? Is it different for cgo vs c-shared? And so on.

These issues - in no particular order - are all about signals, and some would be cleared up by such docs (others are plain bugs):

• runtime: signal handling: c-shared libraries intercepts SIGCHLD and crashes #13042 runtime: signal handling: c-shared libraries intercepts SIGCHLD and crashes
• cmd/go: cannot use 'go test' with code depending on TERM variable #12096 runtime: signal.Ignore not work for SIGTRAP
• runtime: signal_amd64x.go:76 SIGINT on darwin/amd64 causes segfault under c-shared library #13034 runtime: signal_amd64x.go:76 SIGINT on darwin/amd64 causes segfault under c-shared library
• runtime: throw in linked c++ library causes app crash even if caught, on windows platform #12516 runtime: throw in linked c++ library causes app crash even if caught, on windows platform
• runtime: linking a c-shared library disables the C main() SIGINT handler #13028 runtime: linking a c-shared library disables the C main() SIGINT handler
• os/exec: Start sometimes creates processes with signals blocked with go1.5 on OSX #13164 os/exec: Start sometimes creates processes with signals blocked with go1.5 on OSX
• runtime: SIGCONT and SIGTSTP aren't handle-able #8953 runtime: SIGCONT and SIGTSTP aren't handle-able
• runtime: c-shared with LD_PRELOAD does not work for some programs #12465 runtime: c-shared with LD_PRELOAD does not work for some programs
• runtime: crash when C library resets sigaltstack/sigaction settings #7227 runtime: crash when C library resets sigaltstack/sigaction settings
• runtime: deadlock due to blocked glibc-internal signals #12498 runtime: deadlock due to blocked glibc-internal signals
• runtime: nil pointer dereference in sigtrampgo #13363 runtime: nil pointer dereference in sigtrampgo
• runtime: unable to use SIGSTOP to background #4391 runtime: unable to use SIGSTOP to background

[gopherbot]

CL https://golang.org/cl/17877 mentions this issue.