runtime: avoid lock starvation in TestNetpollBreak on Plan 9
TestNetpollBreak was sometimes timing out on Plan 9, where
netpoll_stub.go implements only enough of the network poller
to support runtime timers, using a notetsleep / notewakeup
pair. The runtime.lock which serialises the use of the note
doesn't guarantee fairness, and in practice the netpoll call
used by the test can be starved by the netpoll call from the
scheduler which supports the overall 'go test' timeout.
Calling osyield after relinquishing the lock gives the two
callers a more even chance to take a turn, which prevents
the test from timing out.
Fixes #39437
Change-Id: Ifbe6aaf95336d162d9d0b6deba19b8debf17b071
Reviewed-on: https://go-review.googlesource.com/c/go/+/237698
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
diff --git a/src/runtime/netpoll_stub.go b/src/runtime/netpoll_stub.go
index f86f2f6..3599f2d 100644
--- a/src/runtime/netpoll_stub.go
+++ b/src/runtime/netpoll_stub.go
@@ -49,6 +49,9 @@
notetsleep(&netpollNote, delay)
unlock(&netpollStubLock)
+ // Guard against starvation in case the lock is contended
+ // (eg when running TestNetpollBreak).
+ osyield()
}
return gList{}
}
