-
Notifications
You must be signed in to change notification settings - Fork 13
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
Don't access s_renderInfo from the Unity thread, instead read from s_… #34
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you want a mutex around the write and size-check/read calls so we don't continue to expose a race condition on the s_lastRenderInfo vector.
…continue to expose a race condition on the s_lastRenderInfo vector.
@russell-taylor added. Is that the correct way to use the mutex? |
The lock_guard is a good way to do it. Why did it get changed back to manual locking and unlocking? |
yeah, you definitely want to use lock_guard instead of this last commit. |
This reverts commit aa1ead0.
Looks good. The only remaining issue is that the code may get inconsistent views for the left and right eyes if the value is read in between those. If predictive tracking is doing its job well, the estimates should be close to consistent. |
Added mutex around other s_lastRenderInfo accesses that were missed. Getting confident that this minimally resolves the random crashing we were seeing. Working on OSVR/OSVR-Unity#208 to make sure other crashing issues aren't related. |
Ok, confirmed that it wasn't causing another crashing issue. Merging. |
…lastRenderInfo. Appears to fix the random Unity crashes.