golang/src/runtime/testdata
Michael Anthony Knyszek dfe781e1eb runtime: fix coro interactions with thread-locked goroutines
This change fixes problems with thread-locked goroutines using
newcoro/coroswitch/etc. Currently, the coro paths do not consider
thread-locked goroutines at all and can quickly result in broken
scheduler state or lost/leaked goroutines.

One possible fix to these issues is to fall back on goroutine+channel
semantics, but that turns out to be fairly complicated to implement and
results in significant performance cliffs. More complex thread-lock
state donation tricks also result in some fairly complicated state
tracking that doesn't seem worth it given the use-cases of iter.Pull
(and even then, there will be performance cliffs).

This change implements a much simpler, but more restrictive semantics.
In particular, thread-lock state is tied to the coro at the first call
to newcoro (i.e. iter.Pull). From then on, the invariant is that if the
coro has any thread-lock state *or* a goroutine calling into coroswitch
has any thread-lock state, that the full gamut of thread-lock state must
remain the same as it was when newcoro was called (the full gamut
meaning internal and external lock counts as well as the identity of the
thread that was locked to).

This semantics allows the common cases to be always fast, but comes with
a non-orthogonality caveat. Specifically, when iter.Pull is used in
conjunction with thread-locked goroutines, complex cases (passing next
between goroutines or passing yield between goroutines) are likely to
fail. Simple cases, where any number of iter.Pull iterators are used in
a straightforward way (nested, in series, etc.) from the same
goroutine, will work and will be guaranteed to be fast regardless of
thread-lock state.

This is a compromise for the near-term and we may consider lifting the
restrictions imposed by this CL in the future.

Fixes #65889.
Fixes #65946.

Change-Id: I3fb5791e36a61f5ded50226a229a79d28739b24e
Reviewed-on: https://go-review.googlesource.com/c/go/+/583675
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Austin Clements <austin@google.com>
2024-05-17 19:46:10 +00:00
..
testexithooks runtime: add cgo guard for exit hooks test 2022-09-27 13:46:23 +00:00
testfaketime runtime: platform-independent faketime support 2019-09-04 17:56:53 +00:00
testfds runtime: enforce standard file descriptors open on init on unix 2023-07-25 16:33:33 +00:00
testprog runtime: fix coro interactions with thread-locked goroutines 2024-05-17 19:46:10 +00:00
testprogcgo runtime: fix coro interactions with thread-locked goroutines 2024-05-17 19:46:10 +00:00
testprognet runtime: migrate internal/atomic to internal/runtime 2024-03-25 19:53:03 +00:00
testsuid runtime: implement SUID/SGID protections 2023-06-06 18:49:01 +00:00
testwinlib runtime: support SetUnhandledExceptionFilter on Windows 2023-10-05 08:26:52 +00:00
testwinlibsignal runtime: wait for Go runtime to initialize in Windows signal test 2021-05-21 13:21:00 +00:00
testwinlibthrow runtime: gofmt -w -s 2023-11-17 15:33:38 +00:00
testwinsignal runtime: allow TestCtrlHandler to run in ConPTY 2022-03-18 07:37:53 +00:00
testwintls runtime: fallback to TEB arbitrary pointer when TLS slots are full 2023-04-25 15:37:00 +00:00