Nick Coghlan added the comment:

No, there's no global lock on the import system these days.

Instead, imports are supposed to be atomic on a per-module basis, but issue 
30814 showed that some of the accesses to the shared state management (which 
*is* still supposed to be protected by the import lock) could get into trouble 
given concurrent imports from different threads.

However, the new test exercises an interesting sequence of per-module lock 
acquisition, since each thread effectively runs through this sequence:

- import package # Test case
- import package.submodule # Package init
- import package # Parent package import

That moves back-and-forth between C & Python in a few different places, and 
hence may have been relying on the GIL to keep the parts executed in C atomic.

So now I'm wondering whether or not this new problem might be due to moving the 
_imp.acquire_lock() calls into Python code as part of issue 30814, as that 
creates a window near the start of _find_and_load() where the thread may end up 
holding neither the GIL *nor* the import lock. By contrast, when the import 
lock was acquired in C, then by the time the Python code starts running 
(potentially releasing the GIL), the import lock has already been acquired.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30891>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to