mirror of
https://github.com/golang/go
synced 2024-10-01 03:38:32 -06:00
The Go programming language
32ecf57d22
The implementation and use patterns of onM assume that they run on either the m->curg or m->g0 stack. Calling onM from m->gsignal has two problems: (1) When not on g0, onM switches to g0 and then "back" to curg. If we didn't start at curg, bad things happen. (2) The use of scalararg/ptrarg to pass C arguments and results assumes that there is only one onM call at a time. If a gsignal starts running, it may have interrupted the setup/teardown of the args for an onM on the curg or g0 stack. Using scalararg/ptrarg itself would smash those. We can fix (1) by remembering what g was running before the switch. We can fix (2) by requiring that uses of onM that might happen on a signal handling stack must save the old scalararg/ptrarg and restore them after the call, instead of zeroing them. The only sane way to do this is to introduce a separate onM_signalsafe that omits the signal check, and then if you see a call to onM_signalsafe you know the surrounding code must preserve the old scalararg/ptrarg values. (The implementation would be that onM_signalsafe just calls fn if on the signal stack or else jumps to onM. It's not necessary to have two whole copies of the function.) (2) is not a problem if the caller and callee are both Go and a closure is used instead of the scalararg/ptrarg slots. For now, I think we can avoid calling onM from code executing on gsignal stacks, so just reject it. In the long term, (2) goes away (as do the scalararg/ptrarg slots) once everything is in Go, and at that point fixing (1) would be trivial and maybe worth doing just for regularity. LGTM=iant R=golang-codereviews, iant CC=dvyukov, golang-codereviews, khr, r https://golang.org/cl/135400043 |
||
---|---|---|
api | ||
doc | ||
include | ||
lib | ||
misc | ||
src | ||
test | ||
.hgignore | ||
.hgtags | ||
AUTHORS | ||
CONTRIBUTORS | ||
favicon.ico | ||
LICENSE | ||
PATENTS | ||
README | ||
robots.txt |
This is the source code repository for the Go programming language. For documentation about how to install and use Go, visit http://golang.org/ or load doc/install-source.html in your web browser. After installing Go, you can view a nicely formatted doc/install-source.html by running godoc --http=:6060 and then visiting http://localhost:6060/doc/install/source. Unless otherwise noted, the Go source files are distributed under the BSD-style license found in the LICENSE file. -- Binary Distribution Notes If you have just untarred a binary Go distribution, you need to set the environment variable $GOROOT to the full path of the go directory (the one containing this README). You can omit the variable if you unpack it into /usr/local/go, or if you rebuild from sources by running all.bash (see doc/install.html). You should also add the Go binary directory $GOROOT/bin to your shell's path. For example, if you extracted the tar file into $HOME/go, you might put the following in your .profile: export GOROOT=$HOME/go export PATH=$PATH:$GOROOT/bin See doc/install.html for more details.