[SciPy-dev] Crash in plt.image()
eric at scipy.org
Wed Apr 10 15:42:48 CDT 2002
> >>>>> "Jose" == josegomez <iso-8859-15> writes:
> >> gui_thread before you started to use the plt module. What you
> >> should do is something like this:
> Jose> Exactly, and the plt.image() problem is linked to this
> Jose> as well. So we are all happy now, and i have already put my
> Jose> head inside a bucket :-)
> Well, forgetting gui_thread is a common problem even for the creators
> of the gui_thread code. :)
> Jose> However, it seems a bit harsh for plt.image() to
> Jose> segfault if gui_thread is nor imported, but looking at it,
> Jose> it looks as if it might be a complicated effort to have the
> Jose> plt. methods check whether gui_thread has been imported and
> Jose> if not, import it into the automatically.
> Yes, there were problems with the way Python imports modules and does
> threading. I cant remember the problem right now but Eric is the
> expert on that one.
gui_thread does some shenanigans to force wxPython to be imported in a
background thread. If it is imported in the foreground thread before the import
in the background thread finishes, plt (or any wxPython window) will cause
unpleasant things to happen when used from the command line.
Initially, I tried to have gui_thread spawn a thread that imported
gui_thread_guts in the second thread and then wait for gui_thread_guts to signal
that wxPython was safely imported in the second thread before continuing with
its own import. Unfortunately, Python has a import lock (separate from the
thread lock) that only allows one import to progress at a time. As a result,
blocking gui_thread import and waiting for gui_thread_guts to finish importing
causes a dead lock. Is that confusing enough?
Anyway, that is why you must import gui_thread first thing and then import plt.
If you tried to have plt import gui_thread automatically and block until it was
imported before making its own import of wxPython, you'd get the same deadlock.
For more on the topic see:
I have some ideas about getting rid of gui_thread altogether by rolling its
event proxy stuff into an alternate version of the wxPython shadow classes.
This fixes a lot of problems (which I'm betting only Prabhu and I have run
into) with the proxy side-effects of gui_thread. I haven't looked into the
approach far enough to know if it can also fix the import order problem. I hope
so, but I'm not bettin' more than a nickel...
> Scipy-dev mailing list
> Scipy-dev at scipy.net
More information about the Scipy-dev