This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients RazerM, SamueleSanti, brett.cannon, eric.snow, ncoghlan, serhiy.storchaka
Date 2017-07-05.04:41:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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 (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, 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.
Date User Action Args
2017-07-05 04:41:27ncoghlansetrecipients: + ncoghlan, brett.cannon, eric.snow, serhiy.storchaka, RazerM, SamueleSanti
2017-07-05 04:41:27ncoghlansetmessageid: <>
2017-07-05 04:41:27ncoghlanlinkissue30814 messages
2017-07-05 04:41:27ncoghlancreate