| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Restore critical sections *after* releasing the stop-the-world mutex, rather than before. This prevents deadlocks if there is a pinned mutex, e.g. as done by type_lock_prevent_release().
|
CC @colesbury this could use your expert review. I explored a few different fixes for this deadlock and this seems like the best approach. |
Sorry, something went wrong.
|
Closing this, I think GH-159972 is a better solution, even though it's more code lines changed. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
In the free-threaded build, a thread that holds a critical section and requests a stop-the-world (STW) pause can deadlock against a thread that waits for STW while holding a lock that is not released on detach.
An example of a deadlock:
This PR fixes the deadlock by resuming the critical section after the STW mutex is released. With this change, T1 will block reacquiring TYPE_LOCK, letting T2 complete its STW work first.
This is a change in behavior of the STW APIs. On the contended path, stop_the_world() already released the requester's critical sections (parking detaches). After this PR, they are released until start_the_world() returns rather than being re-acquired when stop_the_world() returns. This is observable to code that takes a critical section itself, calls STW directly, and relies on continuous ownership after the restart.
Note: this PR was created with the assistance of AI agents (Claude and GPT models).