When doing import.test_autotest, test_capi hangs.
It seems that threads 1,2,3 are trying to acquire import lock, which is
owned by thread 4, which is trying to lock some other lock.

Python 2.5.2 (r252:60911, Apr  6 2008, 17:28:23) 
[GCC 4.2.1 20070719  [FreeBSD]] on freebsd7

Ahh, more FreeBSD threading woes.  If no-one beats me to it, I'll be 
able to start taking a look at this when our FreeBSD 7 server is up in 
a week or so.

Hi Trent,

FreeBSD 7 uses libthr as default, which would possibly eliminate this
problem.

I think that this problem is not FreeBSD specific:
- "import test.autotest" runs the whole test suite as a side-effect of
an import statement.
- in the test suite test_capi spawns threads, which also import.
- a lock ensues...

See for example test_threaded_import.py::

    if imp.lock_held():
        # This triggers on, e.g., from test import autotest.
        raise TestSkipped("can't run when import lock is held")

I the test_capi case, I think that the two imports in TestThreadState
should be moved outside the function.

Also, the backtrace file shows two other threads locked in a "import
socket" statement. I suspect problems in test_urllib2.py or
test_urllib2net.py...

I don't that the problem is in tests. For example
  import pygtk
  import gtk
hangs also. I don't have backtrace for PyGtk hang yet, but it hangs in
ucond state too (like test_capi).

In any case, I reproduce the problem on Windows too.

Committed r62229. Please file a separate issue for the gtk module, it's
really another thing.