«

Bruce Sherwood <> writes:
> ...
> The failure of this test case suggests that one cannot do imports
> inside secondary threads started in imported modules, something I keep
> tripping over. But I hope you'll be able to tell me that I'm doing
> something wrong!

As you know multiple threads can be dangerous when they concurrently
change common data structures. Locks are used to protect those
data structures. Locking can introduce other problems - like deadlocks
(something you seem to observe).

I have not looked at the concrete implementation. However, the Python
documentation suggests that the import machinery uses its own locks
(beside the "Global Interpreter Lock"). It seems to be a "thread lock",
which would mean that a thread is not blocked when it already
holds the lock - however any other thread would block.
This easily can lead to a deadlock -- when you wait for the other
thread "in any way".

There should be no problem when you complete the whole import chain
without any waiting for the thread. However, should you start
the GUI main loop inside the import chain, you will never complete
this chain.