
"Mark Hammond" <mhammond@skippinet.com.au> writes:
[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.
Boost isn't in that category. Boost provides a threading library to establish a platform-independent C++ interface for threading, but to date none of the other Boost libraries depend on the use of Boost.Threads. In other words, Boost doesn't require TLS, but it can provide 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.
I take it you are planning to provide a way to get the neccessary TLS from Python's API (in case it isn't lying about elsewhere), but not neccessarily port it to every platform? If so, that sounds like a fine approach. -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution