On Fri, 23 Jan 2009 22:49:34 +0100, Christian Heimes <li...@cheimes.de> wrote:
Jean-Paul Calderone schrieb:
BTW, if you ever find you are starting to write multi-threaded
applications
then you'll really regret it if you reuse code which does imports from
inside functions. If two or more threads try to import a module
simultaneously then one of them might find it that not everything is
defined in the module exists when it tries to use it.
What makes you say this? There is an import lock (beyond the GIL) which
should prevent a thread from ever seeing a partially initialized module.
Partially initialized modules aren't the issue here. One can easily
create a dead lock situation with a mix of threads and imports.
Example:
* module 'mod_a' is imported [import lock is acquired]
* module 'mod_a' spawns a new thread
* the new thread tries to import another module 'mod_b'
Python dead locks here and there is no chance to resolve the lock. The
import of 'mod_b' is waiting for the first import. The first import
hasn't finished because it's still executing the body of 'mod_a'.
In order to avoid the situation you *must* never import a module in a
thread other than the main thread. You should never start a thread in
the body of a submodule, too. A large application should import all its
modules first and then create its threads.
If you really need to import a module from a sub thread or a method that
might be called from a sub thread then you should use the C function
PyImport_ImportModuleNoBlock() or use sys.modules and imp.lock_held().
Of course this is all true and good to know (and I did already ;), but it
doesn't sound like the case being described in the message I was responding
to.
Jean-Paul
--
http://mail.python.org/mailman/listinfo/python-list
