]> granicus.if.org Git - python/commit
PyInterpreterState_New is not thread-safe, and the recent fix to _PyPclose
authorTim Peters <tim.peters@gmail.com>
Sat, 2 Sep 2000 09:16:15 +0000 (09:16 +0000)
committerTim Peters <tim.peters@gmail.com>
Sat, 2 Sep 2000 09:16:15 +0000 (09:16 +0000)
commit412f2460248b21e8d09a57afe98cdb33c16025bc
tree0e52674cb9a87ed87bb9f519bec68e428219b119
parentf2b332dc7e94f5df1965913c6be443980e8727fe
PyInterpreterState_New is not thread-safe, and the recent fix to _PyPclose
can cause it to get called by multiple threads simultaneously.

Ditto for PyInterpreterState_Delete.

Of the former, the docs say "The interpreter lock need not be held, but may
be held if it is necessary to serialize calls to this function".  This
kinda implies it both is and isn't thread-safe.

Of the latter, the docs merely say "The interpreter lock need not be
held.", and the clause about serializing is absent.

I expect it was *believed* these are both thread-safe, and the bit about
serializing via the global lock was meant as a permission rather than a
caution.

I also expect we've never seen a problem here because the Python core
(prior to the _PyPclose fix) only calls these functions once per run.
The Py_NewInterpreter subsystem exposed by the C API (but not used by
Python itself) also calls them, but that subsystem appears to be very
rarely used.

Whatever, they're both thread-safe now.
Python/pystate.c