Message297698
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. |
|
Date |
User |
Action |
Args |
2017-07-05 04:41:27 | ncoghlan | set | recipients:
+ ncoghlan, brett.cannon, eric.snow, serhiy.storchaka, RazerM, SamueleSanti |
2017-07-05 04:41:27 | ncoghlan | set | messageid: <1499229687.94.0.772631174016.issue30814@psf.upfronthosting.co.za> |
2017-07-05 04:41:27 | ncoghlan | link | issue30814 messages |
2017-07-05 04:41:27 | ncoghlan | create | |
|