On 10/10/2010 09:49 AM, Friedrich Romstedt wrote: > 2010/10/2 Eric Firing<efir...@hawaii.edu>: >> On 10/01/2010 09:40 AM, Friedrich Romstedt wrote: >>> There were several question on the user's list in the recent past >>> reporting hangs and similar when using TkAgg backend& interactive >>> mode. >>> >>> 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 > partial answers: > > 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. Eric > > Friedrich ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
