James Henstridge <james@daa.com.au> writes: > I am sure that it would be possible to clear up a lot of these issues > by dropping the Python lock during every gtk API call, though this > would require a fair bit of work to the code generator and testing > (there are a few thousand gtk APIs). This appears to be central to this issue. Can you please comment which of the following statements are incorrect? 1. At any time, any running thread must hold either the Python GIL or the Gtk lock, depending on whether it is executing Python code or Gtk code. 2. Each running thread needs to hold both locks only for the short periods of time where data is transferred from one world to the other. 3. Threads may hold neither lock only if they are about to block, waiting for one of the locks. 4. Currently, when running Gtk code, the thread may also hold the GIL. 5. Before invoking Gtk code, the Gtk lock is explicitly acquired. If this is all true, then it appears indeed that releasing the GIL for any Gtk call would solve your problem. I cannot see why this is difficult to implement, since you already have code in each wrapper to deal with locks, namely to acquire the Gtk lock. Then, in a signal callback, you can just acquire the GIL, and be done. Regards, Martin
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