2010/10/2 Eric Firing<efiring@...229...>:
There were several question on the user's list in the recent past
reporting hangs and similar when using TkAgg backend& interactive
It is known that Tkinter doesn't play well with threading, as long as
one isn't done very carefully.
It could be that matplotlib has implemented it in a way not safe for
Tkinter. This applies if there are Tkinter methods called from
threads other than those which imported Tkinter.
It results in unpredicatable behaviour with exactly the features
reported: Hang-ups, blankening, partial hangup of part of the threads.
Is a rewrite of the Tk interactive code necessary?
I don't see any use of the threading module in backend_tkagg.py or
backend_bases.py. Is that what you are referring to?
Ipython -pylab does use threads (version 0.10), but is intended to avoid
problems by running all user code in a single separate thread.
I just dived a bit into the matplotlib source code, and come up with
When interactive mode is on, the mainloop isn't running at all (see
backend_bases.py:ShowBase). This explains hang-ups when using
interactive mode in a non-shell Python call.
No, I don't think it does. Before going farther, I suggest that you provide specific test cases that fail with mpl from svn. As far as I know, everything works--in or out of interactive mode, in or out of a script, in or out of ipython. There may be problems with some other environments (idle?).
Second, I would be very interested in more information about the
ipython -pylab threading. What do you mean with "running all user
code in a single separate thread"? When it's not the thread importing
Tkinter, the problem persists.
It is the thread importing Tkinter (via the user code), and there is generally no problem.
Tkinter is always cumbersome and needs lots of care ... (at least as
soon as the program wants to do something useful
Also, I cannot see (with reasonable effort) how Threads play a role in
matplotlib. I see there is the Scheduler class in cbook.py, and in
backends/backend_tkagg.py there is "a dict from func-> cbook.Scheduler
threads", but I have no idea how this works. A small hint in the
correct direction would be appreciated! I think it's just a lot
faster although I'm borrowing your time for writing the answer ... I
cannot find any reference to ``.sourced`` in any matplotlib code.
Maybe it's simply dead?
That's the point--threading does not play any role in mpl by default. It looks like John thought about using cbook.Scheduler in backend_tkagg, but ended up not doing so. Hence Scheduler (and its two subclasses, Timeout and Idle) is just a miscellaneous tool in cbook, available to users, but not used in any backend. Yes, that "sourced" attribute is dead; I have now deleted the associated dead code from svn trunk.
On 10/10/2010 09:49 AM, Friedrich Romstedt wrote:
On 10/01/2010 09:40 AM, Friedrich Romstedt wrote: