[issue23068] Add a way to determine if the current thread has the import lock
Nick Coghlan added the comment: Perhaps an API like importlib.util.locks_held() that returns a list of module names? We'd then just iterate over the _module_locks() dictionary, looking for locks where the owner matched the current thread id (alternatively, if speed was critical for Guido's use case, add a separate reverse mapping from tid to locks held) (Unless I've missed something, we don't run user code with the global import lock held any more) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23068 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23068] Add a way to determine if the current thread has the import lock
Eric Snow added the comment: (Unless I've missed something, we don't run user code with the global import lock held any more) Ah. You are correct. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23068 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23068] Add a way to determine if the current thread has the import lock
Guido van Rossum added the comment: Oh. I'd forgotten the PY3 situation is completely different from the PY2 situation. We're still stuck here in PY2 land where there's just the one import lock. I guess not even ctypes can help us find out whether the current thread is holding the import lock (which is the condition we're trying to test for so we can print the warning). Our current hack is to check lock_held() and if it is held wait for up to 5 second (in 10 msec increments) to see if it goes away -- if it doesn't go away it would seem we are holding it in the current thread and then we fail with a rude assert. If it does go away within that time we assume some other thread was doing some lazy importing and we hope they'll be done soon because the whole world is waiting for them. On Wed, Dec 17, 2014 at 6:36 AM, Eric Snow rep...@bugs.python.org wrote: Eric Snow added the comment: (Unless I've missed something, we don't run user code with the global import lock held any more) Ah. You are correct. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23068 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23068 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23068] Add a way to determine if the current thread has the import lock
Nick Coghlan added the comment: Looking at the implementation of PyImport_ImportModuleNoBlock, you should be able to invoke that via ctypes with a nonsense module name to probe for whether or not the current thread has the import lock. A call like 'PyImport_ImportModuleNoBlock(this-is-not-a-legal-module-name)' will always fail with ImportError, but the exception message will be different if another thread holds the import lock. Specifically, it will end with because the import lock is held by another thread. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23068 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23068] Add a way to determine if the current thread has the import lock
Nick Coghlan added the comment: You'd still need to check lock_held() to see if *some* thread is holding the import lock. The non-blocking import API should then let you determine if that thread is the current one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23068 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23068] Add a way to determine if the current thread has the import lock
Guido van Rossum added the comment: Interesting. The Dropbox server team thanks you for the suggestion! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23068 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23068] Add a way to determine if the current thread has the import lock
New submission from Guido van Rossum: imp.lock_held() returns True if *any* thread is currently importing something. I'd like to have an API that can tell whether the *current* thread has the import lock. The implementation keeps track of this, but doesn't make the info available. Use case: print a warning/error if a network call is made during import. -- components: Library (Lib) messages: 232792 nosy: gvanrossum priority: normal severity: normal stage: needs patch status: open title: Add a way to determine if the current thread has the import lock type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23068 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23068] Add a way to determine if the current thread has the import lock
Eric Snow added the comment: Keep in mind that the global import lock is only held long enough to create a module-level lock. The cache of module locks is found at line 166 of Lib/importlib/_bootstrap.py and the code related to module-level locking follows. So unfortunately it won't be as simple as just getting the thread info from the global import lock. Regardless, would it be useful to expose a function in importlib.util that indicates whether or not the current thread is importing a module (actually the names of the modules it is importing)? Something like that would probably check both the global import lock and the module level locks, but make it unnecessary to expose the locks directly. Given the situation with module-level locks I image such a helper is going to be desirable. -- nosy: +brett.cannon, eric.snow, ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23068 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
