Devyn Cairns e1cfc96ee8 Fix locking soundness in PersistentPlugin (#12182) ... # Description There were two problems in `PersistentPlugin` which could cause a deadlock: 1. There were two mutexes being used, and `get()` could potentially hold both simultaneously if it had to spawn. This won't necessarily cause a deadlock on its own, but it does mean that lock order is sensitive 2. `set_gc_config()` called `flush()` while still holding the lock, meaning that the GC thread had to proceed before the lock was released. However, waiting for the GC thread to proceed could mean waiting for the GC thread to call `stop()`, which itself would try to lock the mutex. So, it's not safe to wait for the GC thread while the lock is held. This is fixed now. I've also reverted #12177, as @IanManske reported that this was also happening for him on Linux, and it seems to be this problem which should not be platform-specific at all. I believe this solves it. # User-Facing Changes None # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting		2024-03-12 18:22:29 -05:00
..
mod.rs	Fix locking soundness in PersistentPlugin (#12182)	2024-03-12 18:22:29 -05:00