Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #25796 > unrolled thread

Re: A thread import problem

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: A thread import problem Dieter Maurer <dieter@handshake.de> - 2012-07-22 08:18 +0200

#25796 — Re: A thread import problem

Bruce Sherwood <bruce.sherwood@gmail.com> 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.

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web