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: Clarify how to use various import-related locks
Type: enhancement Stage: needs patch
Components: Interpreter Core Versions: Python 3.5
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Winterflower, brett.cannon, eric.snow, ncoghlan, pitrou
Priority: low Keywords:

Created on 2013-11-22 15:17 by brett.cannon, last changed 2022-04-11 14:57 by admin.

Messages (2)
msg203783 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2013-11-22 15:17
While working on the PEP 451 code I realized that the way we are handling the global import lock along with the per-module lock is a little ad-hoc. For instance, what are we wanting to use the global lock for these days? Mutations of anything off of sys? Reading anything from sys as well? Just to create the module-level locks?

And the per-module lock expects the global lock to be held already, but then does a release implicitly. That seems like the wrong way to structure the context managers; maybe pass in the lock global lock as proof it's being held? Or if we switch to much finer granularity for dealing with sys.modules (especially if it is only for mutation) then we can lock and unlock the global lock entirely within the per-module lock context manager.

At worst I think we should clearly document in the docstrings for the global and per-module context managers what we expect the lock to be used for and then really go through the import code to make sure we are holding it where we want but no more.

To start the conversation, I say the global lock is just to get the per-module locks. The per-module locks are held when finding/loading modules to prevent threading issues of requesting an incomplete module or thinking it isn't being imported when it actually is (which implicitly means holding it when accessing/mutating sys.modules for any module, e.g. trying to fetch a parent module).
msg228409 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-10-03 23:16
Has there been any discussion regarding this elsewhere or is this as far as we've got?
History
Date User Action Args
2022-04-11 14:57:53adminsetgithub: 63894
2016-05-20 09:29:08BreamoreBoysetnosy: - BreamoreBoy
2016-05-18 20:45:39Winterflowersetnosy: + Winterflower
2014-10-03 23:16:58BreamoreBoysetnosy: + BreamoreBoy
messages: + msg228409
2013-11-22 15:17:36brett.cannoncreate