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
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