-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
sf::err()
is not thread-safe
#3003
Comments
sf::priv::printErrLn("Something bad happened at {} because of {}", a, b); It would also be trivial to stick a mutex inside |
BTW, I think it's an acceptable fix to have interleaving error streams without any data race. |
Description
So basically,
sf::Err
is not thread-safe.thread_local
(or SFML's C++98sf::ThreadLocalPtr
equivalent) will make sure there's no race on theDefaultErrStreamBuf
itself, but not on the underlyingstderr
object.If I'm not mistaken, C++11 guarantees thread safety for
stdout
,stderr
, etc. in the sense that no corruption will occur due to multi-threaded access. However, it's still possible that unbuffered characters are interleaved from two places. In C++98, there was no threading model, so I guess no guarantees (might still work in practice).I referenced a PR which is still incomplete, let's continue the discussion there. Unfortunately, pre-C++11 we cannot use
thread_local
.This was original discussed and reported in #1711
Draft PR: #1724
Steps to reproduce
Expected behavior
Application runs through without issues
Actual behavior
You can run into crashes:
Valgrid report:
The text was updated successfully, but these errors were encountered: