"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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4