From: "Martin v. Loewis" <martin@v.loewis.de> > > The issue in a callback is that you need to obtain a thread state > before getting the interpreter lock back. There are two ways to do > this: > > 1. the _tkinter approach: You can guarantee that the call-back occurs > in the context of the same thread that originally released the GIL. > In that case, save the thread state in a global variable, and > restore it inside the callback (see ENTER_TCL/ENTER_PYTHON). > > 2. the "free threading" approach: You assume that callback may occur > in the context of an arbitrary thread, even in a thread that was > not originally created by Python. In that case, inside the > call-back, use PyThreadState_New to create a fresh thread state, > then obtain the GIL for this tread state. When the callback is > done, delete the thread state. You need to preserve a pointer to > the interpreter somehow in a global variable (or provide other > means to locate the interpreter). > > The advantage of 1 is that tracebacks go right back into the main > module, even from the callback; in approach 2, tracebacks go only back > to the entry in the callback (the callback appears to come out of > nowhere). The advantage of 2 is that it is more general. > Can't you at least partly combine the advantages of 1 and 2 by using thread local storage for the global variable? I have no idea if there is a portable way to do this... Thomas
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4