"Mark Hammond" <mhammond@skippinet.com.au> writes:
[David]
"Mark Hammond" <mhammond@skippinet.com.au> writes:
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 ;-)
Yes, this is exactly what I meant. Mozilla is another good example. Mozilla does not require TLS, but indeed builds its own API for it - ie, xpcom does not require it, but does provide it.
While Mozilla therefore has TLS ports for many many platforms, this doesn't help us directly, as we can't just lift their code (MPL, etc). But I believe we could simply lean on them for their implementations at runtime.
Ah, so that void (*funcTLSAlloc)(...) was supposed to be something supplied by the extension writer? Hmm, the Boost interface doesn't work that way, and AFAICT wouldn't be easily adapted to it. It basically works like this: the user declares a special C++ TSS object which internally holds a pointer. That pointer has a different value in each thread, and if you want more storage, you can allocate it and stick it in the pointer. The user can declare any number of these TSS objects, up to some implementation-specified limit. -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution