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.

classification
Title: Expose importlib._bootstrap._ModuleLockManager in importlib.machinery
Type: enhancement Stage:
Components: Library (Lib) Versions:
process
Status: open Resolution:
Dependencies: 30891 Superseder:
Assigned To: Nosy List: brett.cannon, eric.snow, ncoghlan
Priority: normal Keywords:

Created on 2017-07-10 19:11 by brett.cannon, last changed 2022-04-11 14:58 by admin.

Messages (2)
msg298077 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2017-07-10 19:11
Based on all the work currently going into fixing the locking situation for imports, it's probably a good idea to expose it publicly so others can use it.
msg298098 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2017-07-11 01:22
Based on https://github.com/python/cpython/pull/2646/files#r126574323, I'm actually thinking along different lines: I'm starting to think we should move the current sys.modules to sys._modules, and make sys.modules a synchronised wrapper that does the following for all get/set/delete operations:

  # Acquires the global import lock
  # Acquires the relevant module lock
  # Releases the global import lock
  # Mutates sys._modules
  # Releases the module lock

That said, I'm not sure that would be sufficient to give the desired level of atomicity, so exposing ModuleLockManager may actually be a better approach.
History
Date User Action Args
2022-04-11 14:58:48adminsetgithub: 75076
2017-07-11 01:22:17ncoghlansetmessages: + msg298098
2017-07-10 19:11:35brett.cannonsetnosy: + ncoghlan, eric.snow
2017-07-10 19:11:26brett.cannonsetdependencies: + importlib: _find_and_load() race condition on sys.modules[name] check
2017-07-10 19:11:21brett.cannoncreate