[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