languages/go
languages/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-11-02 09:28:34 +00:00
Code Issues Projects Releases Packages 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
used by the shell for job control). The SIGPROF signal is handled
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,
they will remain ignored. Go always registers a handler for the other
signals.
If the Go program is started with either SIGHUP or SIGINT ignored
(signal handler set to SIG_IGN), they will remain ignored.
If the Go program is started with a non-empty signal mask, that will
generally be honored. However, some signals are explicitly unblocked:
the synchronous signals, SIGILL, SIGTRAP, SIGSTKFLT, SIGCHLD, SIGPROF,
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
@ -65,12 +66,12 @@ channels. Specifically, it applies to the signals SIGHUP, SIGINT,
SIGQUIT, SIGABRT, and SIGTERM. It also applies to the job control
signals SIGTSTP, SIGTTIN, and SIGTTOU, in which case the system
default behavior does not occur. It also applies to some signals that
are otherwise ignored: SIGUSR1, SIGUSR2, SIGPIPE, SIGALRM, SIGCHLD,
SIGURG, SIGXCPU, SIGXFSZ, SIGVTALRM, SIGWINCH, SIGIO, SIGPWR, SIGSYS,
SIGINFO, SIGTHR, SIGWAITING, SIGLWP, SIGFREEZE, SIGTHAW, SIGLOST,
SIGXRES, SIGJVM1, SIGJVM2, and any real time signals used on the
system. Note that not all of these signals are available on all
systems.
otherwise cause no action: SIGUSR1, SIGUSR2, SIGPIPE, SIGALRM,
SIGCHLD, SIGCONT, SIGURG, SIGXCPU, SIGXFSZ, SIGVTALRM, SIGWINCH,
SIGIO, SIGPWR, SIGSYS, SIGINFO, SIGTHR, SIGWAITING, SIGLWP, SIGFREEZE,
SIGTHAW, SIGLOST, SIGXRES, SIGJVM1, SIGJVM2, and any real time signals
used on the system. Note that not all of these signals are available
on all systems.
If the program was started with SIGHUP or SIGINT ignored, and Notify
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
When a Go program receives an EPIPE error from the kernel while
writing to file descriptors 1 or 2 (standard output or standard
error), it will raise a SIGPIPE signal. If the program is not
currently receiving SIGPIPE via a call to Notify, this will cause the
program to exit with SIGPIPE. On descriptors other than 1 or 2, the
write will return the 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.
When a Go program writes to a broken pipe, the kernel will raise a
SIGPIPE signal.
If the program has not called Notify to receive SIGPIPE signals, then
the behavior depends on the file descriptor number. A write to a
broken pipe on file descriptors 1 or 2 (standard output or standard
error) will cause the program to exit with a SIGPIPE signal. A write
to a broken pipe on some other file descriptor will take no action on
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