@@ -190,15 +190,14 @@ _get_tcl_lib_path()
190190   By contrast, ENTER_PYTHON and LEAVE_PYTHON are used in Tcl event 
191191   handlers when the handler needs to use Python.  Such event handlers 
192192   are entered while the lock for Tcl is held; the event handler 
193-    presumably needs to use Python.  ENTER_PYTHON releases the lock for 
194-    Tcl and acquires the Python interpreter lock, restoring the 
195-    appropriate thread state, and LEAVE_PYTHON releases the Python 
196-    interpreter lock and re-acquires the lock for Tcl.  It is okay for 
197-    ENTER_TCL/LEAVE_TCL pairs to be contained inside the code between 
198-    ENTER_PYTHON and LEAVE_PYTHON. 
199- 
200-    These locks expand to several statements and brackets; they should 
201-    not be used in branches of if statements and the like. 
193+    presumably needs to use Python.  ENTER_PYTHON acquires the Python 
194+    interpreter lock, restoring the appropriate thread state, and 
195+    LEAVE_PYTHON releases the Python interpreter lock.  Tcl lock is not 
196+    released because that would lead to a race condition: another, 
197+    unrelated call that uses these macros may start (but not finish) in 
198+    the meantime, and a wrong Tcl stack frame will be on top when the original 
199+    handler regains the lock.  Since a handler's Python payload may need to make 
200+    Tkinter calls itself, the Tcl lock is made reentrant. 
202201
203202   If Tcl is threaded, this approach won't work anymore. The Tcl 
204203   interpreter is only valid in the thread that created it, and all Tk 
0 commit comments