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

[Tim Peters]

[Mark Hammond]
> ...
> David, Anthony and I all have this problem today.  Tim Peters can
> see the problem and can see it exists (even if he believes my current
> implementation is incorrect).

I haven't looked at this in at least 2 years.  Back when I did, I thought
there *may* be rare races in how the Win32 classes initialized themselves.
That may not have been the case in reality.

I'd like to intensify the problem, though:  you're in a thread and you want
to call a Python API function safely.  Period.  You don't know anything
else.  You don't even know whether Python has been initialized yet, let
alone whether there's already a thread state, and/or an interpreter state,
sitting around available for you to use.  You don't even know whether you're
a thread created by Python or via some other means.  I believe that, in
order to end this pain forever <heh>, even this case must be made tractable.
It doesn't preclude that a thread knowing more than nothing may be able to
do something cheaper and simpler than a thread that knows nothing at all.

I'd also like to postulate that proposed solutions can rely on a new Python
C API supplying a portable spelling of thread-local storage.  We can
implement that easily on pthreads and Windows boxes, it seems to me to cut
to the heart of several problems, and I'm willing to say that Python
threading doesn't work anymore on other boxes until platform wizards
volunteer code to implement this API there too.  Since the start, Python
threading has been constrained by the near-empty intersection of what even
the feeblest platform thread implementations supply, and that creates
problems without real payback.  Let 'em eat Stackless <wink>.