David Abrahams <dave@boost-consulting.com> writes:
There was no deadlock, as I've said.
Yes, you only said this was a no-no, in http://mail.python.org/pipermail/python-dev/2002-December/031449.html I inferred from that (apparently incorrectly) that the no-no is a deadlock.
The symptom is that Python complains at some point that there's no thread state. It goes away if A releases the GIL before calling into Qt, and reacquires the GIL afterwards.
Now I'm confused. In http://mail.python.org/pipermail/python-dev/2002-December/031424.html you said "A must also release the GIL" and then "the author of A may have had no reason to believe anyone would install Python callbacks in Q". From that I inferred that A does *not* release the GIL (as the author had no reason to). Now you are saying that A releases the GIL. Which one it is?
I speculate that the callback releases the GIL when it is finished, so that when A returns to Python there is no current thread.
That would be a bug in the callback. If there was a thread state when it was called, there should be a thread state when it returns.
Hmm, it seems as though a mutex-protected record of which thread is currently holding the GIL should be enough to handle it.
It depends on what "it" is, here. This one? Q: Is there a way to find out whether the current thread holds the GIL? If so, a mutex-protected record might work, but also might be expensive. Regards, Martin