Prevent possible deadlocks when pressing Escape to cancel recordings#408
Prevent possible deadlocks when pressing Escape to cancel recordings#408cjpais merged 3 commits intocjpais:mainfrom
Conversation
|
I really liked the dynamic keybindings bit when I reviewed from what I recall if you could bring that refactor in too it would be great. I think it starts to set us up a lot better for moving to letting users define all kinds of keybindings if they want |
|
I had claude port over the dynamic bindings, I haven't reviewed honestly. It does work from my brief testing, but would be helpful to have your review as well. I will take a closer look at the code itself when I can. If I just messed things up, feel free to revert the changes |
|
Im running into some issues while testing the dynamic part. I think maybe it would be a nice thing to bring in but I'd rather bring in the fix now rather than later so I'm going to revert to your merge, re-merge, test and pull in |
a291676 to
71f837a
Compare
|
Thanks for the PR! This implementation definitely catches a major flaw. |
…jpais#408) * PRevent possible deadlocks when pressing Escape to cancel recordings * same for sigusr2 --------- Co-authored-by: CJ Pais <[email protected]>
So #224 allows the Escape key to be used to cancel recording. My #401 basically implemented this in a similar (though more generic way) before 224 was merged. Looking at this commit in 401, I think the only thing worth keeping from my implementation is this...
Problem
In toggle mode (non-push-to-talk), the shortcut callback holds the ManagedToggleState
lock while calling action.start() or action.stop(). If the action needs to acquire the
same lock (e.g., cancel_current_operation resets toggle states), this causes a
deadlock.
Solution
Release the lock before calling the action:
Steps after this PR is merged
fnkey on macOS)@cjpais If you'd prefer the slightly more generic approach to handling dynamic keybindings in 2915aea I can also add that to this PR too.