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


Groups > comp.lang.python > #25796

Re: A thread import problem

From Dieter Maurer <dieter@handshake.de>
Subject Re: A thread import problem
Date 2012-07-22 08:18 +0200
References <CA+WuaScBDU_5LcrCrTtDr6N3gHCk9hQ03fA=DT359GCRY=a=KQ@mail.gmail.com> <CA+WuaSeRExxaD9yCNWhXoWqsV_ZqP8DOvdErMRdNS-H_UtzQyg@mail.gmail.com> <87a9yt7bw6.fsf@handshake.de> <CA+WuaSc0Rm5s0CXsm7q7-gfyw+jQxpAGkuajpgFyoAHnTP12sQ@mail.gmail.com>
Newsgroups comp.lang.python
Message-ID <mailman.2418.1342937938.4697.python-list@python.org> (permalink)

Show all headers | View raw


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.

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread


Thread

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

csiph-web