runtime: eliminate arbitrary timeout in TestCgoLockOSThreadExit

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>

1 files changed, 1 insertions, 3 deletions

diff --git a/src/runtime/testdata/testprogcgo/lockosthread.go b/src/runtime/testdata/testprogcgo/lockosthread.go
index 8fcea35f52..e6dce36fb3 100644
--- a/src/runtime/testdata/testprogcgo/lockosthread.go
+++ b/src/runtime/testdata/testprogcgo/lockosthread.go
@@ -94,7 +94,7 @@ func LockOSThreadAlt() {
 		// Exit with the thread locked.
 	}()
 	<-ready
-	for i := 0; i < 100; i++ {
+	for {
 		time.Sleep(1 * time.Millisecond)
 		// Check that this goroutine is running on a different thread.
 		self := C.pthread_self()
@@ -107,6 +107,4 @@ func LockOSThreadAlt() {
 			return
 		}
 	}
-	println("sub thread still running")
-	os.Exit(1)
 }