[Python-Dev] Extension modules, Threading, and the GIL
Mark Hammond
markh@skippinet.com.au
Thu, 9 Jan 2003 13:07:56 +1100
[Tim]
> I'd like to intensify the problem, though:
Good! I was just taking small steps to get to the same endpoint.
> 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.
Agreed 100%. In some ways, I believe this is just the conclusion from my 2
points taken together if we can ignore the current world order. I split
them to try and differentiate the requirements from the current API, but if
we progress to Tim's description, my points become:
1) Becomes exactly as Tim stated.
2.1) Stays the same - release the GIL.
2.2) Goes away - if (1) requires no knowledge of Python's state, there is no
need for extensions to take special action just to enable this.
> 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.
This sounds good to me. After you have done the Win98 version, I volunteer
to port it to Win2k <wink>.
I believe we have a reasonable starting point. Our PEP could have:
* All the usual PEP fluff <wink>
* Define the goal, basically as stated by Tim.
* Define a new C API specifically for this purpose, probably as an
"optional extension" to the existing thread state APIs.
* Define a TLS interface that all ports must implement *iff* this new
API is to be available.
This sounds reasonable to me unless we can see a number of other uses for
TLS - in which case the TLS interface would probably get its own PEP, with
this PEP relying on it. However, I don't see too much need for TLS - once
we have our hands on a Python thread-state, we have a thread-specific
dictionary available today, and a TLS dictionary from inside your Python
code is trivial. From what I can see, we just need platform TLS to get hold
of our thread-state, from which point we can (and do) manage our own thread
specific data.
How does this sound?
Mark.