os/signal: document signal behavior #9896
Comments
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 |
|
Thanks. I was perhaps less clear than I should have been that this issue is Unix-specific. |
|
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
changed the title
|
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):
|
rsc
changed the title
|
CL https://golang.org/cl/17877 mentions this issue. |
This is an attempt to document the current state of signal handling. It's not intended to describe the best way to handle signals. Future changes to signal handling should update these docs as appropriate. update #9896. Change-Id: I3c50af5cc641357b57dfe90ae1c7883a7e1ec059 Reviewed-on: https://go-review.googlesource.com/17877 Reviewed-by: Russ Cox <rsc@golang.org>
|
CL https://golang.org/cl/18062 mentions this issue. |
|
CL https://golang.org/cl/18064 mentions this issue. |
|
CL https://golang.org/cl/18102 mentions this issue. |
|
CL https://golang.org/cl/18108 mentions this issue. |
If non-Go code calls sigaltstack before a signal is received, use sigaltstack to determine the current signal stack and set the gsignal stack to use it. This makes the Go runtime more robust in the face of non-Go code. We still can't handle a disabled signal stack or a signal triggered with SA_ONSTACK clear, but we now give clear errors for those cases. Fixes #7227. Update #9896. Change-Id: Icb1607e01fd6461019b6d77d940e59b3aed4d258 Reviewed-on: https://go-review.googlesource.com/18102 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
|
CL https://golang.org/cl/18150 mentions this issue. |
|
CL https://golang.org/cl/18151 mentions this issue. |
|
Signal handling is now documented. All the issues mentioned above are either fixed, or have CLs out to fix them, except for #12516. We don't need two issues open for that problem, so closing this one. |
Fixes #13034. Fixes #13042. Update #9896. Change-Id: I189f381090223dd07086848aac2d69d2c00d80c4 Reviewed-on: https://go-review.googlesource.com/18062 Reviewed-by: Russ Cox <rsc@golang.org>
Old behavior: 10 consecutive EPIPE errors on any descriptor cause the program to exit with a SIGPIPE signal. New behavior: an EPIPE error on file descriptors 1 or 2 cause the program to raise a SIGPIPE signal. If os/signal.Notify was not used to catch SIGPIPE signals, this will cause the program to exit with SIGPIPE. An EPIPE error on a file descriptor other than 1 or 2 will simply be returned from Write. Fixes #11845. Update #9896. Change-Id: Ic85d77e386a8bb0255dc4be1e4b3f55875d10f18 Reviewed-on: https://go-review.googlesource.com/18151 Reviewed-by: Russ Cox <rsc@golang.org>
When calling a Go function on a C thread, if the C thread already has an alternate signal stack, use that signal stack instead of installing a new one. Update #9896. Change-Id: I62aa3a6a4a1dc4040fca050757299c8e6736987c Reviewed-on: https://go-review.googlesource.com/18108 Reviewed-by: Russ Cox <rsc@golang.org>
We were setting the signal mask of a new m to the signal mask of the m that created it. That failed when that m happened to be the one created by ensureSigM, which sets its signal mask to only include the signals being caught by os/signal.Notify. Fixes #13164. Update #9896. Change-Id: I705c196fe9d11754e10bab9e9b2e7530ecdfa367 Reviewed-on: https://go-review.googlesource.com/18064 Reviewed-by: Russ Cox <rsc@golang.org>
|
CL https://golang.org/cl/18365 mentions this issue. |
Based on comments from Thomas Bushnell. Update #9896. Change-Id: I603b1382d17dff00b5d18f17f8b5d011503e9e4c Reviewed-on: https://go-review.googlesource.com/18365 Reviewed-by: Russ Cox <rsc@golang.org>
The previous behaviour of installing the signal handlers in a separate thread meant that Go initialization raced with non-Go initialization if the non-Go initialization also wanted to install signal handlers. Make installing signal handlers synchronous so that the process-wide behavior is predictable. Update #9896. Change-Id: Ice24299877ec46f8518b072a381932d273096a32 Reviewed-on: https://go-review.googlesource.com/18150 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
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.
The text was updated successfully, but these errors were encountered: