Skip to content

Commit 10c6711

Browse files
committed
Document locking changes for handlers
1 parent ccf51ec commit 10c6711

File tree

1 file changed

+8
-9
lines changed

1 file changed

+8
-9
lines changed

Modules/_tkinter.c

Lines changed: 8 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -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

Comments
 (0)