On 21/06/2012 18:37, Dennis Lee Bieber wrote:
On Thu, 21 Jun 2012 16:19:41 +0100, Rotwang<sg...@hotmail.co.uk>
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 bugtest
Running 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