Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

os/signal: document signal behavior #9896

Closed
ianlancetaylor opened this issue Feb 16, 2015 · 13 comments
Closed

os/signal: document signal behavior #9896

ianlancetaylor opened this issue Feb 16, 2015 · 13 comments
Milestone

Comments

@ianlancetaylor
Copy link
Contributor

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.

@ianlancetaylor ianlancetaylor added this to the Go1.5 milestone Feb 16, 2015
@alexbrainman
Copy link
Member

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
Copy link
Contributor Author

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

@alexbrainman
Copy link
Member

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 rsc changed the title os/signal, runtime: init sets up signal handlers, Stop and Disable turn them off os/signal, runtime: document signal states better Jul 22, 2015
@rsc rsc modified the milestones: Unplanned, Go1.5 Jul 22, 2015
@rsc
Copy link
Contributor

rsc commented 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):

@rsc rsc changed the title os/signal, runtime: document signal states better os/signal: document signal behavior Nov 24, 2015
@rsc rsc modified the milestones: Go1.6, Unplanned Nov 24, 2015
@gopherbot
Copy link
Contributor

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

ianlancetaylor added a commit that referenced this issue Dec 17, 2015
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>
@gopherbot
Copy link
Contributor

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

@gopherbot
Copy link
Contributor

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

@gopherbot
Copy link
Contributor

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

@gopherbot
Copy link
Contributor

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

ianlancetaylor added a commit that referenced this issue Dec 24, 2015
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>
@gopherbot
Copy link
Contributor

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

@gopherbot
Copy link
Contributor

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

@ianlancetaylor
Copy link
Contributor Author

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.

ianlancetaylor added a commit that referenced this issue Jan 5, 2016
Fixes #13034.
Fixes #13042.
Update #9896.

Change-Id: I189f381090223dd07086848aac2d69d2c00d80c4
Reviewed-on: https://go-review.googlesource.com/18062
Reviewed-by: Russ Cox <rsc@golang.org>
ianlancetaylor added a commit that referenced this issue Jan 5, 2016
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>
ianlancetaylor added a commit that referenced this issue Jan 6, 2016
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>
ianlancetaylor added a commit that referenced this issue Jan 6, 2016
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>
@gopherbot
Copy link
Contributor

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

ianlancetaylor added a commit that referenced this issue Jan 8, 2016
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>
ianlancetaylor added a commit that referenced this issue Jan 9, 2016
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>
@golang golang locked and limited conversation to collaborators Jan 7, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants