import lock should be exposed

[gmcm]

BPO	580952
Nosy	@gvanrossum, @tim-one

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/gvanrossum'
closed_at = <Date 2003-02-12.21:54:04.000>
created_at = <Date 2002-07-13.13:06:44.000>
labels = ['interpreter-core']
title = 'import lock should be exposed'
updated_at = <Date 2003-02-12.21:54:04.000>
user = 'https://bugs.python.org/gmcm'

bugs.python.org fields:

activity = <Date 2003-02-12.21:54:04.000>
actor = 'gvanrossum'
assignee = 'gvanrossum'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2002-07-13.13:06:44.000>
creator = 'gmcm'
dependencies = []
files = []
hgrepos = []
issue_num = 580952
keywords = []
message_count = 7.0
messages = ['11556', '11557', '11558', '11559', '11560', '11561', '11562']
nosy_count = 4.0
nosy_names = ['gvanrossum', 'tim.peters', 'gmcm', 'jdhildeb']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue580952'
versions = []

[gmcm]

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.

[gmcm]

Logged In: YES
user_id=4923

Assigning to Tim for initial review.

[tim-one]

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.

[gmcm]

Logged In: YES
user_id=4923

Yes, I would just like to expose the current lock_import and
unlock_import to C and Python.

[jdhildeb]

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.

[jdhildeb]

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 bpo-683257.

[gvanrossum]

Logged In: YES
user_id=6380

OK, this is fixed in CVS for Python 2.3. See bpo-683257 for a
question about backporting.