-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: cmd/go: allow setting runtime godebugs in go.mod / go:debug directives #71283
Comments
asyncpreemptoff=1
by //go:debug
and godebug
section in go.mod
@seankhliao I don't intend to enable to specify other runtime godebugs than |
Rather than start with adding special cases, I think the entire class of godebugs should be considered together first, and only scoped down if it's not appropriate. |
I agree, though I don't have evidences to show how the other options are useful. |
This proposal would have helped #69590 (I think?), where a user was not able to set #71187 was filed as a follow-up, which would be one solution for that particular issue, but this proposal here would be a more general solution, probably. |
there's also a runtime/debug package for a possible more code based api |
Interesting. However, I guess that setting |
A different direction would be to just promote I don't know what would be better. I do wonder though if there should be more of a formal split between:
Compared to the runtime, it seems the cmd/compile folks are more likely to add a debug flag to the compiler that helps them do their day-to-day work (and which can then later help triage reported issues, or help other gophers in the community when they are investigating something, etc.), and I wonder if it makes sense to make it easier to add a setting to the runtime for debugging while clearly communicating that it should not be relied upon (whether that's via GODEBUG, GOREALLYDEBUG, GODEBUG=experimental=foo=1, or something). (I'm pretty sure this type of thing was discussed during the forward/backwards compatibility discussions, but at some point might be worth revisiting given there is now more experience with those changes). (edit: sorry, my typing while distracted was not very successful ;-) |
Historically, the runtime I went down the list, and here's what I think falls into the compatibility/workarounds category:
|
Proposal Details
Now
asyncpreemptoff=1
cannot be specified by//go:debug
:However, there are many situations where disabling async preemption is required as a workaround to make applications work correctly:
I propose to enable to specify
asyncpreemptoff=1
as//go:debug
andgodebug
section in go.mod.Note that it is still possible to specify it by
-ldflags="-X=runtime.godebugDefault=asyncpreemptoff=1"
, but this is pretty hacky.The text was updated successfully, but these errors were encountered: