Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: default to building with the race detector #27339

Closed
sztanpet opened this issue Aug 29, 2018 · 10 comments
Closed

proposal: default to building with the race detector #27339

sztanpet opened this issue Aug 29, 2018 · 10 comments

Comments

@sztanpet
Copy link

Sadly many new gophers do not know about the race detector (anecdotal data from the #go-nuts@freenode). My own experience is that I largely compile with the race detector and only switch it off at the very end for releases.
Sadly I realize that switching the default would be a very disruptive change, but I do wonder if maybe we could do this with the new module features somehow. If modules are already opt-in, maybe there is still time to make the race detector the default for such builds and simply ask people to opt-out instead.

Of course, if something else comes along, it would be great to have a process for making it the default, but that is way too far reaching for my brain.
Thanks for your time.

@gopherbot gopherbot added this to the Proposal milestone Aug 29, 2018
@ALTree
Copy link
Member

ALTree commented Aug 29, 2018

Thanks for the proposal.

The reason this is extremely unlikely to happen:

The cost of race detection varies by program, but for a typical program, memory usage may increase by 5-10x and execution time by 2-20x.

(from https://golang.org/doc/articles/race_detector.html#Runtime_Overheads).

@sztanpet
Copy link
Author

Sure, but the most amount of builds that happen are development builds where the developer cares about race conditions but not about the overhead. Simply opt-out when it matters.

@dominikh
Copy link
Member

I assure you that a 20x slowdown of my dev builds would seriously impact my development process.

@sztanpet
Copy link
Author

sztanpet commented Aug 29, 2018

And if I say that I assure you that you are in the minority? You are also active in the community so it would be easy to opt out. (by that I mean the knowledge that the race detector is by default on, and you should opt-out)

@mvdan
Copy link
Member

mvdan commented Aug 29, 2018

Go already does cheap checks, such as panicking if you read and write from a map concurrently. I agree with others that enabling the race detector by default would mean an unbearable slowdown of the development process.

Also note that the race detector isn't available on all platforms - for example, it currently requires glibc to be installed, so Linux systems based on musl libc cannot use it yet.

@sztanpet
Copy link
Author

Sadly there are too many valid reasons not to do it, I agree. My intention was to maybe re-think it now with modules (and I have no specific reason why a newcomer would use modules but not know about the race-detector). If there is no non-disruptive way to do it, this is all moot of course.

@ianlancetaylor
Copy link
Contributor

Is there some way we could make the race detector more discoverable? For example, would it help to discuss it in Effective Go?

@cznic
Copy link
Contributor

cznic commented Aug 29, 2018

I for one would be probably happy, if go test would force-add the -race option once in N runs. N like 100 or so - or an env var with such default. Or force -race automagically once in N iff the env var exists, etc.

@bcmills
Copy link
Contributor

bcmills commented Sep 6, 2018

For example, would it help to discuss it in Effective Go?

That's #25107 (rejected by @robpike).

@rsc
Copy link
Contributor

rsc commented Sep 19, 2018

Sorry, no. The race detector is great but not the right default.

@rsc rsc closed this as completed Sep 19, 2018
@golang golang locked and limited conversation to collaborators Sep 19, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

9 participants