[Python-Dev] PEP Draft: Simplified Global Interpreter Lock acquisition for extensions (original) (raw)

Mark Hammond mhammond@skippinet.com.au
Thu, 6 Feb 2003 15:54:21 +1100

Good PEP, Mark. I support solving this problem once and for all.

Excellent.

One question: you claim that some implementation of TLS (Thread Local Storage) is required to implement this API, but you don't give enough implementation details to explain this requirement.

I wonder if instead of relying on TLS, you could return a void* pointer from PyAutoThreadStateEnsure() which must be passed back into PyAutoThreadStateRelease()? Or is TLS used for something else too?

OK, I will re-work that portion. I just came up with the following justification:

A platform TLS implementation is required to correctly support
PyThreadState semantics.  It is assumed that it is an error if two
discrete PyThreadStates are used for a single thread.  Comments in
pystate.h ("State unique per thread") support this view, although
it is never directly stated.  Thus, this implementation will require
some abstraction to allow at least per-thread storage of a simple

pointer to a thread's existing PyThreadState.

(I'm not a big fan of TLS, mostly because its API is different for each native thread package; requiring it would make the burden of providing the PyAutoThreadState API bigger.)

In the thread that started this discussion, it was noted that nobody needs to support "screw-ball", or even old, platforms. All complicated extensions that require PyAutoThreadState only run on "major" platforms. Everybody seemed happy if only Windows, Mac and pthreads were supported.

Anyway, I do not propose that a platform provide a complete TLS implementation - all I need is a way to get a per-thread pointer. I expect that if we keep the bar that low, most platforms with a TLS API of any description should be able to provide this facility without too much pain.

I'll post a new PEP up with comments I have recieved, as well as a clarification on the TLS, shortly.

Mark.