I thought it was set to 1 CPU because that's the only way for Go to guarantee th...

bradfitz · on May 28, 2015

No, that was one of the reasons for GOMAXPROCS=1 on App Engine, which is a hardened environment.

For your own code, we trust you to fix your races or deal with the consequences.

Strom · on May 28, 2015

Does this mean that App Engine will never see it raised above 1?

enneff · on May 28, 2015

rsc · on May 28, 2015

I don't know what you mean by "guarantee thread-safety". Whether your program is thread-safe is up to you, not Go.

tokenizerrr · on May 28, 2015

They address this in the document:

> Correctness. There is one non-performance concern. Increased parallelism could make bugs in racy programs more likely to cause crashes or other problems. The setting of GOMAXPROCS=1 may have thus far let those bugs go undetected. Raising it may therefore make buggy programs less reliable. We hope that both the race detector and the introduction of goroutine preemption and interleaving in Go 1.1 has already helped programmers identify and eliminate many such bugs. In any event, we can’t reasonably hobble the performance of working Go programs for fear of breaking buggy ones. If such buggy programs do turn up, the authors can set GOMAXPROCS=1 explicitly to keep them working until the bugs can be fixed.