The go race detector (go test -race) is actually really good at finding these kinds of issues, regardless of GOMAXPROCS. I've gotten a lot more value from running my tests with the race detector in a single process than running the tests with multiple processes and hoping to encounter thread-safety issues in a debuggable way.

Seems like you should probably never run the tests with -race. Is there a downside from that being the default?

The only real downside is that it slows things down quite a bit (30s vs 12s for a full test run in my current project; I've seen both better and worse ratios in other projects). I've also seen a project that made heavy use of generated code and a race-enabled build would choke on the very large source files. But overall I agree that it seems worthwhile to make -race the default.

Actually that is exactly the case in a library of mine[0]. Its not a bug of my code directly but due to non-POSIX compliance of Linux that triggers only with multiple threads (setuid does set the uid only for the executed thread and not for the others of the same process - unlike the manual page and POSIX states). Its a cornercase but I also explicitly raise the GOMAXPROCS in the test case to trigger it[1].

[0] https://github.com/sarnowski/mitigation

[1] https://github.com/sarnowski/mitigation/blob/master/mitigati...

(context for others, where you reported this)

https://code.google.com/p/go/issues/detail?id=1435

It is fair to claim that this is "non-POSIX compliance of Linux": the underlying system call interface of an operating system is not something subject to a standard. The mapping from the POSIX-compliant C library to the underlying system calls is allowed to be quite complex, and in fact most of the high-level POSIX functions map to system calls designed for much more general use cases, or arguments with different kinds of struct packing.

You really just should not have been coding directly against the system calls of the operating system: that isn't portable; and later in the discussion, this was specifically addressed ("The syscall package is not for general use. It has no documentation. That's not going to change. When we have a working Setuid etc they will be made available as part of package os."). What sucks is that they seem to have never gotten around to implementing os.Setuid.

You should assume Go's creators thought of this. There are performance implications, as it adds overhead if it's not necessary. Most people when writing libraries will decide if it's necessary or useful enough to use CPU multithreading. Single core is common in cloud servers. This is a really bad idea that will never happen.

Yes! They know it's bad (the documentation says something like "we'll do something smarter later"), but even just a default of 2 would be much better IMO.