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

[Mark Hammond]

[Martin]
> David Abrahams <dave@boost-consulting.com> writes:
>
> > We also have a TSS implementation in the Boost.Threads library.  I
> > haven't looked at the ACE code myself, but I've heard that every
> > component depends on many others, so it might be easier to extract
> > useful information from the Boost implementation.
>
> Without looking at either Boost or ACE, I would guess that neither
> will help much: We would be looking for TLS support for AtheOS, BeOS,
> cthreads, lwp, OS/2, GNU pth, Solaris threads, SGI threads, and Win
> CE.  I somewhat doubt that either Boost or ACE aim for such a wide
> coverage.

We could simply have a "pluggable TLS" design.

It seems that everyone who has this requirement is interfacing to a complex
library (com, xpcom, Boost, ACE), and in general, these libraries also
require TLS.

So consider an API such as:

PyTSM_HANDLE Py_InitThreadStateManager(
			void (*funcTLSAlloc)(...),
			...
			PyInterpreterState = NULL);

void Py_EnsureReadyToRock(PyTSM_HANDLE);
void Py_DoneRocking(PyTSM_HANDLE);
...

Obviously the spelling is drastically different, but the point is that we
can lean on the extension module itself, rather than the platform, to
provide the TLS.  In the case of Windows and a number of other OS's, you
could fallback to a platform implementation if necessary, but in the case of
xpcom, for example, you know that xpcom also defines its own TLS API, so
anywhere we need the extension module, TLS comes for "free", even if no one
has ported the platform TLS API to the Python TLS API.  Our TLS requirements
are very simple, and could be "spelt" in a small number of function
pointers.

Such a design also handles any PyInterpreterState issues - we simply assert
if the passed pointer is non-NULL, and leave it to someone who cares to fix
<wink>.

Mark.