[Python-bugs-list] [ python-Bugs-613233 ] test_threadedtempfile hangs
noreply@sourceforge.net
noreply@sourceforge.net
Wed, 25 Sep 2002 13:00:44 -0700
Bugs item #613233, was opened at 2002-09-23 10:57
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=613233&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
>Assigned to: Tim Peters (tim_one)
Summary: test_threadedtempfile hangs
Initial Comment:
Python 2.3's test_threadedtempfile tends to hang at the
beginning (on my Linux machine), due to a race condition
with the global import lock of the interpreter. The
problem does not show up if you run "python
test_threadedtempfile.py" directly but it does if you
run a module that imports test_threadedtempfile.
The race condition seems to be caused by the threads
that this test launches, each of which wants to create a
new Random() object. This in turn causes deadlocking
attempts to import the 'time' module.
I suggest to change the test_threadedtempfile module,
renaming _test() to test_main() and not actually
starting the test automatically, as was done in
test_threaded_import.
This change also removes the need for the buggy line 32:
tempfile.gettempdir() \
# Do this now to avoid spurious races later
(I suspect that more generally the confusing import
deadlocks would be worth another bug report, although
I'm not sure what could be done about it. Maybe just
detecting deadlocks before they occur and raising
ImportErrors with a clear error message?)
----------------------------------------------------------------------
>Comment By: Tim Peters (tim_one)
Date: 2002-09-25 16:00
Message:
Logged In: YES
user_id=31435
I believe your analysis is on target, Armin. I'll fix it. It hangs
under Windows too, BTW. The problem appears unique to
2.3, and was introduced when a rewrite of tempfile.py started
to import random.
I agree that the import lock can be confusing, but also unsure
what can be done about it. Running gobs of code as a side
effect of merely importing is dubious practice, so I'm not sure
I want to make that easier <wink>. In any case, a thread
waiting for the import lock simply can't know whether the
thread holding it will ever let go of it; a lock here seems the
right solution to a different problem.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=613233&group_id=5470