aboutsummaryrefslogtreecommitdiff
path: root/src/runtime/env_test.go
AgeCommit message (Collapse)Author
2020-06-19runtime, syscall: use local cache for Setenv/Getenv in Plan 9Richard Miller
In os.Getenv and os.Setenv, instead of directly reading and writing the Plan 9 environment device (which may be shared with other processes), use a local copy of environment variables cached at the start of execution. This gives the same semantics for Getenv and Setenv as on other operating systems which don't share the environment, making it more likely that Go programs (for example the build tests) will be portable to Plan 9. This doesn't preclude writing non-portable Plan 9 Go programs which make use of the shared environment semantics (for example to have a command which exports variable definitions to the parent shell). To do this, use ioutil.ReadFile("/env/"+key) and ioutil.WriteFile("/env/"+key, value, 0666) in place of os.Getenv(key) and os.Setenv(key, value) respectively. Note that CL 5599054 previously added env cacheing, citing efficiency as the reason. However it made the cache write-through, with Setenv changing the shared environment as well as the cache (so not consistent with Posix semantics), and Clearenv breaking the sharing of the environment between the calling thread and other threads (leading to unpredictable behaviour). Because of these inconsistencies (#8849), CL 158970045 removed the cacheing again. This CL restores cacheing but without write-through. The local cache is initialised at start of execution, manipulated by the standard functions in syscall/env_unix.go to ensure the same semantics, and exported only when exec'ing a new program. Fixes #34971 Fixes #25234 Fixes #19388 Updates #38772 Change-Id: I2dd15516d27414afaf99ea382f0e00be37a570c3 Reviewed-on: https://go-review.googlesource.com/c/go/+/236520 Run-TryBot: David du Colombier <0intro@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Fazlul Shahriar <fshahriar@gmail.com> Reviewed-by: David du Colombier <0intro@gmail.com>
2015-06-03runtime: fix TestFixedGOROOT to properly restore the GOROOT env var after testBrad Fitzpatrick
Otherwise subsequent tests won't see any modified GOROOT. With this CL I can move my GOROOT, set GOROOT to the new location, and the runtime tests pass. Previously the crash_tests would instead look for the GOROOT baked into the binary, instead of the env var: --- FAIL: TestGcSys (0.01s) crash_test.go:92: building source: exit status 2 go: cannot find GOROOT directory: /home/bradfitz/go --- FAIL: TestGCFairness (0.01s) crash_test.go:92: building source: exit status 2 go: cannot find GOROOT directory: /home/bradfitz/go --- FAIL: TestGdbPython (0.07s) runtime-gdb_test.go:64: building source exit status 2 go: cannot find GOROOT directory: /home/bradfitz/go --- FAIL: TestLargeStringConcat (0.01s) crash_test.go:92: building source: exit status 2 go: cannot find GOROOT directory: /home/bradfitz/go Update #10029 Change-Id: If91be0f04d3acdcf39a9e773a4e7905a446bc477 Reviewed-on: https://go-review.googlesource.com/10685 Reviewed-by: Andrew Gerrand <adg@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
2015-03-09runtime: do not share underlying envs/argv arrayDavid Crawshaw
Removes a potential data race between os.Setenv and runtime.GOROOT, along with a bug where os.Setenv would only sometimes change the value of runtime.GOROOT. Change-Id: I7d2a905115c667ea6e73f349f3784a1d3e8f810d Reviewed-on: https://go-review.googlesource.com/6611 Reviewed-by: Keith Randall <khr@golang.org>