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