languages/go
languages/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-09-15 22:20:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

os/signal: clarify signal doc

Browse source 
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>
This commit is contained in:
Ian Lance Taylor 2016-01-07 09:41:45 -08:00
parent 161f2e85ee
commit 8971d61835
1 changed files with 30 additions and 20 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

50
src/os/signal/doc.go
View file

@ -42,17 +42,18 @@ causes the program to exit with a stack dump. A SIGTSTP, SIGTTIN, or
SIGTTOU signal gets the system default behavior (these signals are SIGTTOU signal gets the system default behavior (these signals are
used by the shell for job control). The SIGPROF signal is handled used by the shell for job control). The SIGPROF signal is handled
directly by the Go runtime to implement runtime.CPUProfile. Other directly by the Go runtime to implement runtime.CPUProfile. Other
signals are ignored. signals will be caught but no action will be taken.
If the Go program is started with either SIGHUP or SIGINT ignored, If the Go program is started with either SIGHUP or SIGINT ignored
they will remain ignored. Go always registers a handler for the other (signal handler set to SIG_IGN), they will remain ignored.
signals.
If the Go program is started with a non-empty signal mask, that will If the Go program is started with a non-empty signal mask, that will
generally be honored. However, some signals are explicitly unblocked: generally be honored. However, some signals are explicitly unblocked:
the synchronous signals, SIGILL, SIGTRAP, SIGSTKFLT, SIGCHLD, SIGPROF, the synchronous signals, SIGILL, SIGTRAP, SIGSTKFLT, SIGCHLD, SIGPROF,
and, on GNU/Linux, signals 32 (SIGCANCEL) and 33 (SIGSETXID) and, on GNU/Linux, signals 32 (SIGCANCEL) and 33 (SIGSETXID)
(SIGCANCEL and SIGSETXID are used internally by glibc). (SIGCANCEL and SIGSETXID are used internally by glibc). Subprocesses
started by os.Exec, or by the os/exec package, will inherit the
modified signal mask.
Changing the behavior of signals in Go programs Changing the behavior of signals in Go programs
@ -65,12 +66,12 @@ channels. Specifically, it applies to the signals SIGHUP, SIGINT,
SIGQUIT, SIGABRT, and SIGTERM. It also applies to the job control SIGQUIT, SIGABRT, and SIGTERM. It also applies to the job control
signals SIGTSTP, SIGTTIN, and SIGTTOU, in which case the system signals SIGTSTP, SIGTTIN, and SIGTTOU, in which case the system
default behavior does not occur. It also applies to some signals that default behavior does not occur. It also applies to some signals that
are otherwise ignored: SIGUSR1, SIGUSR2, SIGPIPE, SIGALRM, SIGCHLD, otherwise cause no action: SIGUSR1, SIGUSR2, SIGPIPE, SIGALRM,
SIGURG, SIGXCPU, SIGXFSZ, SIGVTALRM, SIGWINCH, SIGIO, SIGPWR, SIGSYS, SIGCHLD, SIGCONT, SIGURG, SIGXCPU, SIGXFSZ, SIGVTALRM, SIGWINCH,
SIGINFO, SIGTHR, SIGWAITING, SIGLWP, SIGFREEZE, SIGTHAW, SIGLOST, SIGIO, SIGPWR, SIGSYS, SIGINFO, SIGTHR, SIGWAITING, SIGLWP, SIGFREEZE,
SIGXRES, SIGJVM1, SIGJVM2, and any real time signals used on the SIGTHAW, SIGLOST, SIGXRES, SIGJVM1, SIGJVM2, and any real time signals
system. Note that not all of these signals are available on all used on the system. Note that not all of these signals are available
systems. on all systems.
If the program was started with SIGHUP or SIGINT ignored, and Notify If the program was started with SIGHUP or SIGINT ignored, and Notify
is called for either signal, a signal handler will be installed for is called for either signal, a signal handler will be installed for
@ -89,15 +90,24 @@ Notify for that signal, the signal will once again be blocked.
SIGPIPE SIGPIPE
When a Go program receives an EPIPE error from the kernel while When a Go program writes to a broken pipe, the kernel will raise a
writing to file descriptors 1 or 2 (standard output or standard SIGPIPE signal.
error), it will raise a SIGPIPE signal. If the program is not
currently receiving SIGPIPE via a call to Notify, this will cause the If the program has not called Notify to receive SIGPIPE signals, then
program to exit with SIGPIPE. On descriptors other than 1 or 2, the the behavior depends on the file descriptor number. A write to a
write will return the EPIPE error. This means that, by default, broken pipe on file descriptors 1 or 2 (standard output or standard
command line programs will behave like typical Unix command line error) will cause the program to exit with a SIGPIPE signal. A write
programs, while other programs will not crash with SIGPIPE when to a broken pipe on some other file descriptor will take no action on
writing to a closed network connection. the SIGPIPE signal, and the write will fail with an EPIPE error.
If the program has called Notify to receive SIGPIPE signals, the file
descriptor number does not matter. The SIGPIPE signal will be
delivered to the Notify channel, and the write will fail with an EPIPE
error.
This means that, by default, command line programs will behave like
typical Unix command line programs, while other programs will not
crash with SIGPIPE when writing to a closed network connection.
Go programs that use cgo or SWIG Go programs that use cgo or SWIG