Found new dashboard test flakes for:

#!watchflakes
post <- pkg == "runtime" && test == "TestCgoLockOSThreadExit"

--- FAIL: TestCgoLockOSThreadExit (33.56s)
    crash_test.go:58: /tmp/gobuilder-mips64/tmp/go-build1708738987/testprogcgo.exe LockOSThreadMain (1.426881411s): ok
    crash_test.go:58: /tmp/gobuilder-mips64/tmp/go-build1708738987/testprogcgo.exe LockOSThreadAlt: exec: WaitDelay expired before I/O complete

— watchflakes

cc @golang/mips

This failure mode does not appear to be platform-dependent — I think it's just a timing-sensitive test. Probably needs some kind of more explicit synchronization.

Hmm. Actually, there are three different failure modes here:

• The openbsd-amd64-71 failure is runtime: test timeouts on openbsd-.*-71 builders #57585.
• The dragonfly-amd64-622 failure looks like a timing-sensitive behavior in the test — it only waits for 100ms before arbitrarily failing if the thread's destructor hasn't run yet.
• The linux-mips-rtrk failure is something different — the I/O from the test process took longer than we expected to flush.

I've filed the dragonfly-amd64-622 failure mode separately as #58247.

The linux-mips-rtrk failure could have just been a long C compilation time (compare #44422) running the test up against its timeout, which causes the computed WaitDelay (5% of the remaining deadline) to be reduced.

We also increase the minimum WaitDelay based on GO_TEST_TIMEOUT_SCALE, but up until CL 455521 that wasn't explicitly set in the environment on this builder. I suspect that that environment change may have reduced the likelihood of this failure mode on the mips builders.

Found new dashboard test flakes for:

#!watchflakes
post <- pkg == "runtime" && test == "TestCgoLockOSThreadExit" && `WaitDelay expired`

--- FAIL: TestCgoLockOSThreadExit (1.26s)
    proc_test.go:983: /data/golang/workdir/tmp/go-build4088272690/testprogcgo.exe LockOSThreadMain: exec: WaitDelay expired before I/O complete

— watchflakes

#58901