-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
gh-127081: lock non-re-entrant *pwent
calls
#132748
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
Conversation
The libc setpwent, getpwent, and endpwent functions are not thread-safe. Protect them with mutexs in free-threading builds.
*pwent
calls
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.
We need a critical section here. Py_CLEAR
and Py_DECREF
are re-entrant (as in, they can invoke the eval loop), so a mutex is prone to lock-ordering or re-entrancy deadlocks.
Actually, sorry, we need to fix subinterpreter thread-safety here too. We can't do that with a critical section. Could you adjust the mutex to go over solely the libc calls? |
Hmm, yeah, good point. I guess we can just defer the decrefs until exit. |
…ility of re-entrancy.
… they are strongly referenced by that, so we can dec-ref them safely.
The libc setpwent, getpwent, and endpwent functions are not thread-safe. Protect them with mutexs in free-threading builds.