python.exe/Tkinter hang on exit
support at internetdiscovery.com
Wed Sep 12 04:18:10 CEST 2001
On Fri, 07 Sep 2001 05:06:27 GMT, Howard Lightstone
<howard at eegsoftware.com> wrote:
>Mike Clarkson wrote:
>> What diagnostics are you using to detemine that it's a mutex hang?
>> Can you tell which thread is hung - a running python.exe has 2 threads
>> and loading Tkinter adds I think 3 more threads. The one that is
>> steadily consuming CPU is probably the Tk mainloop. Can you tell if
>> it's that one, one of the other threads started with Tk, or an
>> original Python thread that gets locked?
>There are several bugs related listed on the Sourceforge Python bug list:
> #216289 and #453489
>For that list, I ran the short test program in #453489 (12 lines, see below)
>in both Pythonw and Python executables.
>I used Taskinfo2000 to look at internals before/after termination.
>Here is the data again:
Can you tell if it's that one, one of the other threads started with
Tk, or an original Python thread that gets locked?
In other words, can you look before the
then after the import to see which threads are
started by loading Tk and identify if it's one of these
hanging, or one of the original Python threads.
>I *may* have been overeager to blame the ole mutex since there is also a
>There is no special logic. Tkinter (if nothing else is assigned) binds to
>the WM_DELETE_WINDOW message.
># bug 453489
>from Tkinter import *
> print 'foo'
> print 'bar'
>Button(root, text='Quit', command=root.quit).pack()
Change root.quit to root.destroy and put a
after the mainloop(). Quit only quits the mainloop; it does not in
and of itself destroy the Tk intepreter or delete the instance.
(Another idea, as ^C always works, might be to define a quit method
that raises SystemExit.)
>I have been forced to put LOTS of print messages into my code, use some
>methods to send sys.stdout/sys.syserr messages to a window, curse mightily,
>and run pythonw only.....
I've looked at this problem before without success, and really would
like to identify if it's one of the Tk threads that's hanging, or one
Upon reflection I realize that Python is doing something that Tk
itself cannot do: importing Tk into a DOS console application.
At least up to Tk 8.4 this has never been possible with Tcl.
So even though this problem to my knowledge has never been
seen with Pure Tk, it does not mean it it not a Tk problem: any
Tk of 8.3.3 or less could never run in this mode.
More information about the Python-list