Fix: MakeScreenshot could crash when called from outside of VideoDriver::Tick, and acquire video buffer before taking game state lock to prevent erratic fast forward #9155
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.
Closes #9140, closes #9147.
Motivation / Problem
While there was nothing wrong with #9140 itself, it was discovered that MakeScreenshot locking is broken anyway, as described in #9147.
Description
This attempts to fix the issue by adding yield mutex for draw thread, recursive mutex for video buffer and slightly awry locking sequence in MakeScreenshot. Because order of these locking operations interacts with #9140 this cannot be easily split into two commits, so it is already integrated with previous PR.
Limitations
I'm not too happy about the complexity of this, maybe it is just better to disallow screenshots from rcon when real video driver is loaded...
Checklist for review
Some things are not automated, and forgotten often. This list is a reminder for the reviewers.