proposal: runtime: disallow changing GOMAXPROCS

[valyala]

The runtime.GOMAXPROCS function allows updating the number of p at any time during the program execution. This could be useful before go1.5 when GOMAXPROCS was set to 1 by default and when goroutine scheduler wasn't very good.

Now the goroutine scheduler is great and GOMAXPROCS equals to the number of available CPU cores by default. So there are no major reasons to change it during program execution. Additionally, GOMAXPROCS may be overridden via environment variable at program start if required:

GOMAXPROCS=1 ./path/to/program

The ability to change GOMAXPROCS in runtime complicates the code in runtime and sync packages. @dvyukov should agree with this :)

The documentation to runtime.GOMAXPROCS explicitly says:

This call will go away when the scheduler improves.

Maybe it's time to make runtime.GOMAXPROCS no-op, i.e. just return the GOMAXPROCS value set at program start?

[dvyukov]

FWIW we use GOMAXPROCS=1 in some tests, and I think cluster management systems may need finer-grained control over GOMAXPROCS during dynamic machine partitioning.

[ianlancetaylor]

Yes, if your VM is reconfigured, or if somebody wants to call sched_setaffinity on your process, then it still makes sense to change GOMAXPROCS.

[XANi]

Wouldn't that make LockOSThread() way less useful tho ? Currently you can just increase number of goroutines before calling it to be sure you will have other threads to use for rest of goroutines

[ianlancetaylor]

There isn't any real interaction between LockOSThread and GOMAXPROCS. GOMAXPROCS is essentially the number of operating system threads that are permitted to run Go code concurrently. When a goroutine is ready to run, the scheduler permits it to run if there are fewer than GOMAXPROCS threads running. That is true whether or not a goroutine is locked to a thread.

[rsc]

This would certainly eliminate a source of bugs, but we're aware of uses both inside and outside Google that update GOMAXPROCS in reaction to containers or VMs reconfiguring the number of available effective CPUs. We can't do this before Go 2, but even in Go 2 I don't think we can do this.

@valyala you are wrong. There are good reasons to set GOMAXPROCS to > NUMCPU. The scheduler is not that good at all - it is not even preemptive!

[davecheney]

This issue has been closed for several months, please do not consent further.

We don't the issue tracker to ask questions. Please see https://golang.org/wiki/Questions for good places to continue this discussion. Thanks.