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.

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.

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

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.

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!

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.