Skip to content

Conversation

@duaneg
Copy link
Contributor

@duaneg duaneg commented Apr 20, 2025

The libc setpwent, getpwent, and endpwent functions are not thread-safe. Protect them with mutexs in free-threading builds.

The libc setpwent, getpwent, and endpwent functions are not thread-safe.
Protect them with mutexs in free-threading builds.
@picnixz picnixz changed the title gh-127081: lock non-re-entrant *pwent calls gh-127081: lock non-re-entrant *pwent calls Apr 20, 2025
Copy link
Member

@ZeroIntensity ZeroIntensity left a 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.

@ZeroIntensity
Copy link
Member

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?

@duaneg
Copy link
Contributor Author

duaneg commented Apr 20, 2025

Py_CLEAR and Py_DECREF are re-entrant...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.

@kumaraditya303 kumaraditya303 self-requested a review May 21, 2025 16:51
… they are

strongly referenced by that, so we can dec-ref them safely.
@kumaraditya303 kumaraditya303 merged commit 458e330 into python:main May 22, 2025
42 checks passed
lkollar pushed a commit to lkollar/cpython that referenced this pull request May 26, 2025
Pranjal095 pushed a commit to Pranjal095/cpython that referenced this pull request Jul 12, 2025
taegyunkim pushed a commit to taegyunkim/cpython that referenced this pull request Aug 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants