[following is windows-specific stuff]
I seem to recall that the reason for requiring a dynamically linked version was solely for automatically cleaning up thread_specific_ptr's at
"Johan Nilsson" <johan.nilsson@esrange.ssc.se> wrote in message news:c9k069$9jf$1@sea.gmane.org... [snip performance profiling discussion] thread
exit - is that right?
Yes.
I've in the past made a solution based on lazy cleanup of previously allocated TLS data - i.e. when someone attempts to alloc a TLS (aka TSS) slot/data, the currently invalid data (belonging to an "ex-thread") is deleted. This requires some metadata to be globally available to all threads, and that this data is tagged with the owning threads id, but is certainly doable.
I'll have to think about this.
It could also be possible to expose a manual TLS-data "garbage-collection" routine, e.g. "collect_tss_data", for the user's really nedding it. Not beautiful, but considering the options ...
There are a few potential problems though (off the top of my head):
1. Performance - each creation of thread-specific data required exclusive access to the metadata. If this is a real issue or not depends on
I had thought of something like this, too. Or of exposing cleanup functions that could be called from the user's dllmain (if they have one) rather than requiring Boost.Threads to have its own dllmain function to detect when threads go away. And there's the idea that Roland proposed some time ago, which could be built on top of this, of having Boost.Threads create a "pseudo-dll" on the fly that can detect when threads go away and tell Boost.Threads about it. Unfortunately, I still haven't been able to spend much time actually trying these ideas out. Most of my recent Boost time has been spent working on finishing the conversion of Boost.Threads docs to BoostBook format and updating them. the
real-world scenario.
Yes.
Developers sensitive to this should anyway try to create only one thread_specific_ptr to host all their TSS data. Also, TLS slots are a limited resource (especially under earlier NT versions). Or is this automatically managed by the current TSS implementation?
Boost.Threads now uses only one real TLS slot no matter how many thread_specific_ptrs you create, so this shouldn't be a problem.
2. Operating system's reuse of thread id's. This could (in theory) cause data to be hanging around longer than necessary, but should otherwise not be causing problems as each thread should only be able to access data created by themselves.
I can see reuse of thread ids being a problem, but I'm not sure I understand the rest of this.
3. Destruction-time for TSS data would be indeterminate (unless explicitly clearing things up).
Unless using one of the alternative dllmain schemes I mentioned above. Mike