Nick Coghlan added the comment:
Documenting explicitly what I believe the expected order of module lock
acquisition would be in this case:
Thread A acquires package.subpackage lock
Thread B blocks on package.subpackage lock
Thread A acquires package lock
Thread A releases package lock
Thread A releases package.subpackage lock
Thread B acquires & immediately releases package.subpackage lock
Looking at https://hg.python.org/cpython/rev/64f195790a3a#l4.367 (the commit
for issue 22557), there's a potentially suspect change in the scope of a
"_PyImport_AcquireLock/_PyImport_ReleaseLock" pair inside
PyImport_ImportModuleLevelObject
Specifically, I think we may now have a race condition at
https://github.com/python/cpython/blob/master/Python/import.c#L1534, where two
threads can *both* end up trying to initialize the same module, since we're no
longer holding the global import lock around that "mod =
PyDict_GetItem(interp->modules, abs_name);" call and the associated state
updates where the first thread indicates that it is already initializing that
module so the second thread should just wait for it to finish doing so.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30814>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
