[Python-Dev] Extension modules, Threading, and the GIL

[Tim Peters]

[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