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: import lock should be exposed
Type: Stage:
Components: Interpreter Core Versions:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: gvanrossum Nosy List: gmcm, gvanrossum, jdhildeb, tim.peters
Priority: normal Keywords:

Created on 2002-07-13 13:06 by gmcm, last changed 2022-04-10 16:05 by admin. This issue is now closed.

Messages (7)
msg11556 - (view) Author: Gordon B. McMillan (gmcm) Date: 2002-07-13 13:06
See
http://mail.python.org/pipermail/import-sig/2002-July/000179.html

In brief, a good import hook needs to use an import
lock. But if it creates it's own import lock, you have the
possibility of a deadlock, since PyImport_ImportModuleEx
still uses the core lock. So one thread can end up
acquiring the hook's lock, then seeking the core lock.
While another holds the core lock, but  does an import
(routed through the hook) and seeks the hook's lock.

Seems to me exposing the core lock through
imp.acquire_lock() and imp.release_lock() would
allow a properly coded hook  to avoid this.
msg11557 - (view) Author: Gordon B. McMillan (gmcm) Date: 2002-07-13 13:10
Logged In: YES 
user_id=4923

Assigning to Tim for initial review.
msg11558 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2002-07-14 21:06
Logged In: YES 
user_id=31435

I don't understand how imports work, at least not at this 
level.  I note that the current lock_import() and 
unlock_import() arrange to implement a reentrant lock:  in 
the absence of you supplying a patch, are these the 
functions you would like to see exposed?  Given the games 
being played here, it seems too dangerous to expose the 
*underlying* lock's acquire and release methods directly.

Assigned to Guido for cogitation.
msg11559 - (view) Author: Gordon B. McMillan (gmcm) Date: 2002-07-14 21:34
Logged In: YES 
user_id=4923

Yes, I would just like to expose the current lock_import and 
unlock_import to C and Python.
msg11560 - (view) Author: Jason Hildebrand (jdhildeb) Date: 2003-02-09 04:05
Logged In: YES 
user_id=173690

For what it's worth, Webware for Python users are exposed to
this bug, too, as Webware is multithreaded and uses an
import hook.  This has caused me some amount of grief, and
I've been happy to figure out the cause (the import
collisions were causing really weird things to happen).

I've attached a patch to import.c which exposes the
acquire_lock() and release_lock() functions.  Since
modifying Webware's import routine to use this these
functions, I have been completely unable to reproduce the
buggy behaviour (which had previously been easy to reproduce).

It would be great to have this merged in for Python 2.3, as
projects using both custom import hooks and threads have no
other reliable way of solving this problem.
msg11561 - (view) Author: Jason Hildebrand (jdhildeb) Date: 2003-02-09 04:32
Logged In: YES 
user_id=173690

I've attached the patches against both 2.3-2.2.99 and 2.2.2;
they are available in patch # 683257.
msg11562 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2003-02-12 21:54
Logged In: YES 
user_id=6380

OK, this is fixed in CVS for Python 2.3. See #683257 for a
question about backporting.
History
Date User Action Args
2022-04-10 16:05:30adminsetgithub: 36888
2002-07-13 13:06:44gmcmcreate