net
net copied to clipboard
golang
trace: avoid race between event recycling and freeTrace()
When there are less than 5 events in a trace, the tr.events slice is backed by the tr.eventsBuf array. This leads to a race between the background recycler invocation in unref(). If freeTrace() runs before the recycler goroutine, tr.events just consists of empty event objects when the recycler finally gets to them, and thus the user's recycling function cannot do any useful recycling (as event.What is now nil). So in the case where the array is shared, we make a copy and pass that to the recycler, so that recycling can be done in the background but freeTrace can be run immediately.
Since the copying is only done when there are less than 5 events to copy, it should not have a significant performance impact.
I added a bunch of test cases around this, perhaps too many. And, you will be horrified at how we wait for all the recyclers to run in the test. I did this to avoid modifying the code to add synchronization between the entire recycling operation and the test, and to avoid the test hanging for a long time when it's in the failing state. Suggestions for improvement would be most welcome!
This PR (HEAD: 5e073f0749a8014dc1fd07a754e8db1b3badfedc) has been imported to Gerrit for code review.
Please visit https://go-review.googlesource.com/c/net/+/238302 to see it.
Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info
Message from Gobot Gobot:
Patch Set 1:
Congratulations on opening your first change. Thank you for your contribution!
Next steps: A maintainer will review your change and provide feedback. See https://golang.org/doc/contribute.html#review for more info and tips to get your patch through code review.
Most changes in the Go project go through a few rounds of revision. This can be surprising to people new to the project. The careful, iterative review process is our way of helping mentor contributors and ensuring that their contributions have a lasting impact.
During May-July and Nov-Jan the Go project is in a code freeze, during which little code gets reviewed or merged. If a reviewer responds with a comment like R=go1.11 or adds a tag like "wait-release", it means that this CL will be reviewed as part of the next development cycle. See https://golang.org/s/release for more details.
Please don’t reply on this GitHub thread. Visit golang.org/cl/238302. After addressing review feedback, remember to publish your drafts!
Message from Go Bot:
Patch Set 1:
Congratulations on opening your first change. Thank you for your contribution!
Next steps: A maintainer will review your change and provide feedback. See https://golang.org/doc/contribute.html#review for more info and tips to get your patch through code review.
Most changes in the Go project go through a few rounds of revision. This can be surprising to people new to the project. The careful, iterative review process is our way of helping mentor contributors and ensuring that their contributions have a lasting impact.
During May-July and Nov-Jan the Go project is in a code freeze, during which little code gets reviewed or merged. If a reviewer responds with a comment like R=go1.11 or adds a tag like "wait-release", it means that this CL will be reviewed as part of the next development cycle. See https://golang.org/s/release for more details.
Please don’t reply on this GitHub thread. Visit golang.org/cl/238302. After addressing review feedback, remember to publish your drafts!