[David Abrahams] > ... > but AFAICT there _is_ a Python core issue here: there's no way to find > out whether you've already got the GIL**, so if you _might_ have to acquire > it, you must always acquire it. > > **If I'm wrong about that, please let me know. It isn't obvious from > the documentation. It's true -- you can't know whether you have the GIL, unless you code up another layer of your own machinery to keep track of who has the GIL. Mark Hammond faces this issue (in all its multifacted glories) in the Win32 extensions, and built some C++ classes there to help him out. It's difficult at best, and last I looked (several years ago) I wasn't convinced Mark's approach was 109% reliable. The worst it gets in the Python core is in posixmodule.c's _PyPclose, which needs to build a new interpreter state from scratch, in order to build a new thread state from scratch, in order to acquire the GIL, in order to call some Py API functions. This isn't as hard as it *can* get, because in that function we know the thread executing does not hold the GIL. The now-defunct Thread-SIG used to have bouts of angst over all this. I think we eventually figured out a better approach there, but it required real work to implement, and nobody had time for that. The only that's changed since then is that nobody remembers the better approach anymore <0.9 wink>. happy-new-year-ly y'rs - tim
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