Reset Mutex (Issue 2429) #2460
Merged
Reset Mutex (Issue 2429) #2460
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ble the crash handler Use version-tagged zips for the downloaded packages
-- Still tests failing and some coverage missing after refactor
…all from zips, not from files
Always add the temp download area to the search patch for downloading wheels. This should work for the MacOS shim where we have to download a signed wheel for pygame and then be sure to use that in preference to the PyPI version
Remove (again) `upgrade_pip` + Tidy
|
Can't get this to pass all tests -- I assume that the PiOS ones are because the relevant VM is down or something? Unless anyone objects, I'll merge it soon and then let people play with it. I've tested on Linux & Windows so it's only if MacOS has an issue. @carlosperate (or anyone) please take it for a spin on MacOS if you can. The only reasonable test is to make sure the Mutex continues to work in normal circs -- ie you start one session and attempt to start another; but then doesn't prevent the second instance if the first session is killed hard |
|
@tjguk thank you so much for all your work on this. |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When the app hard crashes (eg via a faulty appimage) while the Mutex is held, there is no way to reset it short of writing code to do that or rebooting! This change adds a small change which will reset the Mutex if it's orphaned but will not have any effect if it's still owned by another process (its primary purpose).
It's not easy to test -- least of all automatically. I've only been able to ad hoc test it on Linux -- and that may well be the only platform on which the problem occurs, as on other platforms the shared memory which the Mutex uses is released by the OS; on Linux it has to be released by the app.
My standard approach is to use the appimage binary which crashes consistently on my Linux Mint setup. That then leaves the Mutex held but orphaned. Without this PR, Mu will never start up; with the PR in place Mu will re-own the shared memory and will acquire the Mutex. Conversely, if the Mutex is in fact held by a running Mu instance, with this PR, things happen as they should and the second instance does not run.