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 f86f2f61748ed8c78fb8b647a191f14431915c00..3599f2d01b7a2b968ac7d90fdd3c6ede7d52babf 100644 (file)
--- a/src/runtime/netpoll_stub.go
+++ b/src/runtime/netpoll_stub.go
@@ -49,6 +49,9 @@ func netpoll(delay int64) gList {
 
                notetsleep(&netpollNote, delay)
                unlock(&netpollStubLock)
+               // Guard against starvation in case the lock is contended
+               // (eg when running TestNetpollBreak).
+               osyield()
        }
        return gList{}
 }