During review of CL 704615, a suggestion was made that spawning a
goroutine inside a call to secret.Do result in a panic. I agreed with
this at the time, but had missed that this had been extensively
discussed on the proposal. Revert the behavior back to what was agreed
upon.
Change-Id: Ifaa9e24bd03ecbd870ae2217137d1a9527c96842
Reviewed-on: https://go-review.googlesource.com/c/go/+/728920
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
// The compiler turns a go statement into a call to this.
func newproc(fn *funcval) {
gp := getg()
- if goexperiment.RuntimeSecret && gp.secret > 0 {
- panic("goroutine spawned while running in secret mode")
- }
-
pc := sys.GetCallerPC()
systemstack(func() {
newg := newproc1(fn, gp, pc, false, waitReasonZero)
// - Currently only supported on linux/amd64 and linux/arm64. On unsupported
// platforms, Do will invoke f directly.
// - Protection does not extend to any global variables written by f.
-// - Any attempt to launch a goroutine by f will result in a panic.
+// - Protection does not extend to any new goroutines made by f.
// - If f calls runtime.Goexit, erasure can be delayed by defers
// higher up on the call stack.
// - Heap allocations will only be erased if the program drops all