aboutsummaryrefslogtreecommitdiff
path: root/src/runtime/testdata/testprogcgo/lockosthread.go
AgeCommit message (Collapse)Author
2023-02-02runtime: eliminate arbitrary timeout in TestCgoLockOSThreadExitBryan C. Mills
This test previously failed if running a new pthread took longer than a hard-coded 100ms. On some slow or heavily-loaded builders, that scheduling latency is too short. Since the point of this test is to verify that the background thread is not reused after it terminates (see #20395), the arbitrary time limit does not seem helpful: if the background thread fails to terminate the test will time out on its own, and if the main goroutine is scheduled on the background thread the test will fail regardless of how long it takes. Fixes #58247. Change-Id: I626af52aac55af7a4c0e7829798573c479750c20 Reviewed-on: https://go-review.googlesource.com/c/go/+/464735 Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2021-12-13all: gofmt -w -r 'interface{} -> any' srcRuss Cox
And then revert the bootstrap cmd directories and certain testdata. And adjust tests as needed. Not reverting the changes in std that are bootstrapped, because some of those changes would appear in API docs, and we want to use any consistently. Instead, rewrite 'any' to 'interface{}' in cmd/dist for those directories when preparing the bootstrap copy. A few files changed as a result of running gofmt -w not because of interface{} -> any but because they hadn't been updated for the new //go:build lines. Fixes #49884. Change-Id: Ie8045cba995f65bd79c694ec77a1b3d1fe01bb09 Reviewed-on: https://go-review.googlesource.com/c/go/+/368254 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2017-10-11runtime: terminate locked OS thread if its goroutine exitsAustin Clements
runtime.LockOSThread is sometimes used when the caller intends to put the OS thread into an unusual state. In this case, we never want to return this thread to the runtime thread pool. However, currently exiting the goroutine implicitly unlocks its OS thread. Fix this by terminating the locked OS thread when its goroutine exits, rather than simply returning it to the pool. Fixes #20395. Change-Id: I3dcec63b200957709965f7240dc216fa84b62ad9 Reviewed-on: https://go-review.googlesource.com/46038 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>