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