-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix locking soundness in PersistentPlugin #12182
Fix locking soundness in PersistentPlugin #12182
Conversation
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 nushell#12177, as Ian 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.
Thanks for digging in and figuring it out! |
Not that it's related but right after this PR I get this error compiling on macos now. So, back to using
|
I haven't made any dependency changes today, so unfortunately I think it's probably upstream again |
Looks to me like that got stabilized with rustc 1.76.0 fyi, so it's using something newer than it should |
yup, agreed, it's upstream. A little aggravating that we're a couple rust releases from that being in stable for us. We try to stay two versions behind. |
Issue submitted |
@devyn Thank you for tackling all of plugin stuff! It's hard to get it right with bug free at once. I'm happy to see all improvements on plugin system |
Description
There were two problems in
PersistentPlugin
which could cause a deadlock: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 sensitiveset_gc_config()
calledflush()
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 callstop()
, 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