On 21/06/2012 18:37, Dennis Lee Bieber wrote:
On Thu, 21 Jun 2012 16:19:41 +0100, Rotwang<[email protected]> declaimed the following in gmane.comp.python.general:import threading, Tkinter, os, pickle class savethread(threading.Thread): def __init__(self, value): threading.Thread.__init__(self) self.value = value def run(self): print 'Saving:', with open(os.path.join(os.getcwd(), 'bugfile'), 'wb') as f: pickle.dump(self.value, f) print 'saved' class myclass(object): def gui(self): root = Tkinter.Tk() root.grid() def save(event): savethread(self).start() root.bind('s', save)Each time your "s" runs you are creating a NEW thread.
Yes, that's the whole point: I want the object's state to be saved in the background while I can continue using the GUI without having to wait (in the original module where I noticed the problem, the thread pickles a copy of the object whose gui method created it, rather than the object itself - that way I can make changes to the object without interfering with the work being done by pickle.dump).
root.wait_window() m = myclass() m.gui() --- end bugtest.py --- Here's the problem: suppose I fire up Python and type >>> import bugtestRunning in the interpreter rather than as a program...and then click on the Tk window that spawns and press 's'. Then 'Saving:' gets printed, and an empty file named 'bugfile' appears in my current working directory. But nothing else happens until I close the Tk window; as soon as I do so the file is written to and 'saved' gets printed. If I subsequently type >>> bugtest.m.gui() and then click on the resulting window and press 's', then 'Saving: saved' gets printed and the file is written to immediately, exactly as I would expect. Similarly if I remove the call to m.gui from the module and just call it myself after importing then it all works fine. But it seems as if calling the gui within the module itself somehow stops savethread(self).run from finishing its job while the gui is still alive.Since you never kill the previous thread, you might have a binding to left-over multiple threads; at the least, the Python scheduler may be swapping between threads.
Which previous thread do you mean? The problem happens when save has only been called once.
The task swapping probably gives the threads time to flush output. With just the first run thread condition, the process may go back to the Tk mainloop and not return to the thread to completely flush data. Especially with the use of .wait_window(), which is supposed to lock the application until the window is destroyed. If overly aggressive, it might even lock up swapping back to the thread to allow it to flush.Can anyone help?Don't run from the interactive interpreter?
Thanks. -- Hate music? Then you'll hate this: http://tinyurl.com/psymix -- http://mail.python.org/mailman/listinfo/python-list
