[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.


> 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

    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
    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.