-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
testing/synctest: experimental package for testing concurrent code #69687
Comments
Related Issues and Documentation
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.) |
This proposal has been added to the active column of the proposals project |
Putting on hold until we get enough implementation experience. |
How would that experience happen over the coming months? Can we perhaps try an experimental implementation before this proposal gets accepted? |
This proposal already is for an experimental implementation. My understanding is that we're running into issues right off the bat even with that. Though perhaps that shouldn't block this from going through the proposal process. |
We've got one issue which I'm aware of, which is the question of how synctest bubbles interact with testing.T.Cleanup functions. I think there are two clear answers to that question, which I presented in #67434 (comment):
My preference is to move the synctest API to the testing package, still behind a GOEXPERIMENT=synctest guard, but I'm fine with either of the above alternatives. Keeping the proposal-as-written also doesn't preclude us adding a testing.T method in the future if it turns out to be a good idea. I don't think we're going to gain substantial further experience with synctest without an experimental implementation that people can try out. |
It seems like this proposal only has to decide whether to create GOEXPERIMENT=synctest, not exactly what it means. (The point of the GOEXPERIMENT is to be able to check in the code and change what it means over time, in service of #67434.) Does it make sense to approve the GOEXPERIMENT so that we can try some version of the code in Go 1.24 and find out if there are any problems besides t.Cleanup? |
Damien also reports having converted some etcd tests that were using clockwork to just use synctest, and lots of testing things melted away and the tests just passed. So we do know that it works well enough for real usage, which seems to me to justify making it available as an experiment to get more real-world experimentation. |
You're right. I'm not quite sure what thought process led to me putting this one on hold. Maybe I meant to put #67434 on hold pending experience with the GOEXPERIMENT? Who even knows. |
I'm not sure about the word "idle". Could we just call it blocked? @neild also mentioned "durably blocked" at some point offline. How about that? Or, "bubbly blocked"? |
Based on the discussion above, this proposal seems like a likely accept. The proposal is to add |
Change https://go.dev/cl/591997 mentions this issue: |
Change https://go.dev/cl/629735 mentions this issue: |
Add an internal (for now) implementation of testing/synctest. The synctest.Run function executes a tree of goroutines in an isolated environment using a fake clock. The synctest.Wait function allows a test to wait for all other goroutines within the test to reach a blocking point. For #67434 For #69687 Change-Id: Icb39e54c54cece96517e58ef9cfb18bf68506cfc Reviewed-on: https://go-review.googlesource.com/c/go/+/591997 Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
No change in consensus, so accepted. 🎉 The proposal is to add |
@neild This change (a package available only when an experiment is set) should be mentioned in Go 1.24 release notes, otherwise users might not know it exists and might not test it sufficiently, is that right? |
Proposal Details
This is an offshoot of #67434. See that proposal for prior discussion and more details.
I propose adding a new testing/synctest package to aid in testing concurrent code. This package will be initially guarded by a GOEXPERIMENT flag: It will be present only in toolchains built with GOEXPERIMENT=synctest. After we've gained some experience with the experimental package, we will make the decision to drop the flag requirement and fully release it, abandon the experiment and remove it, or amend it.
The package API is as follows:
The text was updated successfully, but these errors were encountered: