Great! Will place it in the Demo directory. Now all I need is an
application for threads :-)
> BUG: The attached module worms around this, but the following self-
> contained little program usually freezes with most threads reporting
> [Example using "import" in a thread, followed by correct analysis of
> what goes wrong]
>
> If that's right, a perhaps not-too-bad workaround would be to introduce a
> static "you can't interrupt this thread" flag in ceval.c, check it before
> giving up interpreter_lock, and have IMPORT_NAME set it & restore (plain
> clearing would not work) it around its call to import_module. To its
> credit, there's something wonderfully perverse about fixing a race via an
> unprotected static <grin>.
Can't we agree that the user is responsible for this? It would be
simple enough (and a more common programming style in any case) to
import the needed modules in the main thread. After all, ANYTHING
that modifies global variables and doesn't know about threads should
be serialized by the caller. Only the most basic operations are
guaranteed to be atomic -- to be exact: everything that is one
instruction of the Python Virtual Machine and does not call other
Python code.
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
URL: <http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>