Skip to content
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

Remove unnecessary mutexes #1891

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

CendioOssman
Copy link
Member

Remove many of the existing mutexes as they are either not needed, or provide incomplete protection and hence give a false sense of security.

We are currently only running viewer decoders on threads, so there is very little code that needs thread safety. And we can probably make do by writing that code in a way that doesn't access global objects¹.

The exception is the WinVNC code, which is very thread heavy. But it is unmaintained and will not be a blocker for this.

¹ I'd really like to enforce this, but I don't know how without sprinkling a thread id check in lots of places.

The decodered is already flagged as strictly ordered, which means it
will only be used from a single thread at a time.
It uses the size_t type, which might not otherwise be defined.
@CendioOssman CendioOssman requested a review from samhed January 6, 2025 14:15
A false return value from these methods result in an exception anyway,
so let's keep things simple and throw the exception right away.
Reset individual contexts the same way we reset all contexts, i.e. by
deleting and recreating them. Avoids surprises by having a consistent
method.
Decoders are run in threads, and not everything in the logging system is
thread safe.

Normally decoders consider errors to be fatal and throw an exception.
But the H.264 decoder wants to be able to tolerate misbehaving H.264
encoders.
This is not providing adequate protectection in more complex cases, and
we're not making use of threads in a way that should require this.

The exception is the WinVNC code, which is very thread heavy. But it is
unmaintained and will not be a blocker for this.
This is not providing protection for all of the logging, so it gives a
false sense of security. We're also not making use of this as we have
barely any threading.

The exception is the WinVNC code, which is very thread heavy. But it is
unmaintained and will not be a blocker for this.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant