[Python-Dev] PEP Draft: Simplified Global Interpreter Lock acquisition for extensions
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 PyAutoThreadState_Ensure() which must be passed back into
> PyAutoThreadState_Release()? 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.