[Tkinter-discuss] why this prog.py crash on win32 ?

Jeff Epler jepler at unpythonic.net
Thu Oct 14 17:29:53 CEST 2004

I don't know much about the current state of Tkinter and threads, much
less on win32.  However, this 2002 article may be relevant to you:

This block of comment comes from a relatively recent CVS version of
_tkinter.c (parts re-flowed to fit in 80 columns):
/* The threading situation is complicated.  Tcl is not thread-safe, except
   when configured with --enable-threads.  So we need to use a lock around all
   uses of Tcl.  Previously, the Python interpreter lock was used for this.
   However, this causes problems when other Python threads need to run while
   Tcl is blocked waiting for events.

   To solve this problem, a separate lock for Tcl is introduced.  Holding it is
   incompatible with holding Python's interpreter lock.  The following four
   macros manipulate both locks together.

   ENTER_TCL and LEAVE_TCL are brackets, just like Py_BEGIN_ALLOW_THREADS and
   Py_END_ALLOW_THREADS.  They should be used whenever a call into Tcl is made
   that could call an event handler, or otherwise affect the state of a Tcl
   interpreter.  These assume that the surrounding code has the Python
   interpreter lock; inside the brackets, the Python interpreter lock has been
   released and the lock for Tcl has been acquired.

   Sometimes, it is necessary to have both the Python lock and the Tcl lock.
   (For example, when transferring data from the Tcl interpreter result to a
   Python string object.)  This can be done by using different macros to close
   the ENTER_TCL block: ENTER_OVERLAP reacquires the Python lock (and restores
   the thread state) but doesn't release the Tcl lock; LEAVE_OVERLAP_TCL
   releases the Tcl lock.

   By contrast, ENTER_PYTHON and LEAVE_PYTHON are used in Tcl event handlers
   when the handler needs to use Python.  Such event handlers are entered while
   the lock for Tcl is held; the event handler presumably needs to use Python.
   ENTER_PYTHON releases the lock for Tcl and acquires the Python interpreter
   lock, restoring the appropriate thread state, and LEAVE_PYTHON releases the
   Python interpreter lock and re-acquires the lock for Tcl.  It is okay for
   ENTER_TCL/LEAVE_TCL pairs to be contained inside the code between

   These locks expand to several statements and brackets; they should not be
   used in branches of if statements and the like.

   If Tcl is threaded, this approach won't work anymore. The Tcl interpreter is
   only valid in the thread that created it, and all Tk activity must happen in
   this thread, also. That means that the mainloop must be invoked in the
   thread that created the interpreter. Invoking commands from other threads is
   possible; _tkinter will queue an event for the interpreter thread, which
   will then execute the command and pass back the result. If the main thread
   is not in the mainloop, and invoking commands causes an exception; if the
   main loop is running but not processing events, the command invocation will

   In addition, for a threaded Tcl, a single global tcl_tstate won't be
   sufficient anymore, since multiple Tcl interpreters may simultaneously
   dispatch in different threads. So we use the Tcl TLS API.

These comments may not apply to your version of Tcl and Tkinter, since they
depend on the compile options for Tcl and the Python version.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/tkinter-discuss/attachments/20041014/7f4bce45/attachment.pgp

More information about the Tkinter-discuss mailing list