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.

Author pitrou
Recipients belopolsky, brett.cannon, christian.heimes, grahamd, gvanrossum, ncoghlan, pitrou
Date 2010-07-13.13:36:38
SpamBayes Score 0.0661279
Marked as misclassified No
Message-id <1279028192.3236.29.camel@localhost.localdomain>
In-reply-to <>
> Pretty much anything mentioned in PEP 302 is what is being protected.

Alright, my question was more along the lines of "what *needs* to be
protected". The import lock is currently like the GIL: a very simple
(and therefore suboptimal) answer to a complex problem.

I am wondering whether one could revive Marc-André's idea here:

If the sole purpose is to prevent multi-threaded import of the same
module, then we can have an internal dict of temporary locks for each
module being imported. The "global import lock" itself can be reduced to
protecting accesses to this dict.

If custom (third-party) import hooks are commonly non-thread safe, then
the "global import lock" can still be taken when such an import hook is
called. But built-in import mechanisms can be more tolerant.
Date User Action Args
2010-07-13 13:36:41pitrousetrecipients: + pitrou, gvanrossum, brett.cannon, ncoghlan, belopolsky, christian.heimes, grahamd
2010-07-13 13:36:39pitroulinkissue8098 messages
2010-07-13 13:36:38pitroucreate