| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
✅ Deploy Preview for python-cpython-preview canceled.
|
Sorry, something went wrong.
|
IMHO, we should keep all cached process-level resource availability/capability checks as static global variables. I'm specifically talking about the following group (and any others we might add in the future): cpython/Tools/c-analyzer/cpython/ignored.tsv Lines 16 to 23 in b7e4f1d Making any of them per-interpreter is unnecessary since the value will always be uniform for the process. Moving them to _PyRuntimeState did not seem correct because the value is independent of Python's runtime and should not change across init/fini cycles. |
Sorry, something went wrong.
|
tl;dr I'd rather we keep dup3_works as a static variable and not move it to the module state. In the case of dup3_works the only concern I had was if there were any potential races, since the value is set lazily after runtime init. Looking at it again, there really isn't a race there. The only real race would be if two threads both see a -1 value (line 9463, if (dup3_works == -1)) and set the variable. However, that has no consequences if we assume word-size values like this are written atomically, which they should be. So let's not worry about it. |
Sorry, something went wrong.
Okay, I understood :) |
Sorry, something went wrong.
|
Thanks for working on this though! |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
dup3_works is safe to be ported as the module state variable since there is just one writing accessing in L9462.
Even if there are duplicated updatings for the dup3_works due to the race condition, dup3_works will not be updated anymore after the initial trial.