[Python-Dev] Threading and callbacks - missing documentation (original) (raw)
Thomas Heller thomas.heller@ion-tof.com
Fri, 12 Apr 2002 09:31:19 +0200
- Previous message: [Python-Dev] Threading and callbacks - missing documentation
- Next message: [Python-Dev] Threading and callbacks - missing documentation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 ENTERTCL/ENTERPYTHON). 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 PyThreadStateNew 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
- Previous message: [Python-Dev] Threading and callbacks - missing documentation
- Next message: [Python-Dev] Threading and callbacks - missing documentation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]