Closed
Description
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.
Metadata
Metadata
Assignees
Type
Projects
Relationships
Development
No branches or pull requests
Activity
alexbrainman commentedon Feb 16, 2015
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 commentedon Feb 17, 2015
Thanks. I was perhaps less clear than I should have been that this issue is Unix-specific.
alexbrainman commentedon Feb 17, 2015
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.
[-]os/signal, runtime: init sets up signal handlers, Stop and Disable turn them off[/-][+]os/signal, runtime: document signal states better[/+]rsc commentedon Nov 24, 2015
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):
[-]os/signal, runtime: document signal states better[/-][+]os/signal: document signal behavior[/+]gopherbot commentedon Dec 16, 2015
CL https://golang.org/cl/17877 mentions this issue.
os/signal: document signal handling
4 remaining items
runtime: adjust gsignal stack to current signal stack
gopherbot commentedon Dec 26, 2015
CL https://golang.org/cl/18150 mentions this issue.
gopherbot commentedon Dec 28, 2015
CL https://golang.org/cl/18151 mentions this issue.
ianlancetaylor commentedon Jan 2, 2016
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.
runtime: disable a signal by restoring the original disposition
os, runtime: better EPIPE behavior for command line programs
runtime: preserve signal stack when calling Go on C thread
runtime: set new m signal mask to program startup mask
gopherbot commentedon Jan 7, 2016
CL https://golang.org/cl/18365 mentions this issue.
os/signal: clarify signal doc
runtime: for c-archive/c-shared, install signal handlers synchronously