"Johan Nilsson" <johan.nilsson@esrange.ssc.se> wrote in message news:c9mk92$815$1@sea.gmane.org...
"Michael Glassford" <glassfordm@hotmail.com> wrote in message news:c9kodd$krt$1@sea.gmane.org...
"Johan Nilsson" <johan.nilsson@esrange.ssc.se> wrote in message news:c9k069$9jf$1@sea.gmane.org...
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 ...
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
having Boost.Threads create a "pseudo-dll" on the fly that can detect when threads go away and tell Boost.Threads about it.
Could this cause problems in the future, when Windows will make use of the protect-memory-from-execution functionality in recent Intel
[snip] this, of processors
(sorry, I just don't remember the proper name)?
I don't know. I was worried about that myself, but haven't looked into it yet.
An alternative could be to have Boost.Threads automatically create a background thread to periodically collect unowned thread-specific data.
Now if boost threads could have priority assigned to them to make this a (corresponding to) THREAD_PRIORITY_IDLE thread - is that in
This could also be used in addition to lazy cleanup instead of as an alternative, and seems to have the same problems. the
works?
2. Operating system's reuse of thread id's. This could (in
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.
Highly theoretical:
1. Thread A is created with id:1 2. Thread A" creates thread_specificic_ptr (first time), implicitly allocating TLS slot. 3. Thread A exits 4. Thread B is created, gettting the recycled id of the first thread (id:1) 5. Thread B creates thread_specific_ptr; this is the first time so
implementation now also tries to perform a 'lazy' cleanup of any unowned data. There are still data allocated by Thread A, but this is mapped
The (unfinished) changes on the thread_dev branch do implement thread priorties. They won't make it into the next Boost release, but I hope they will be in the one after that. [snip] theory) the through
the thread's id and so can't be detected as ready for collection.
I follow as far as this.
Thread B can still create it's own data,
How does thread B know that it needs to create its own data--i.e., what prevents it from thinking that thread A's data is its own and using it? Here's a specific case I have in mind: the implementation of the thread class on the thread_dev branch. In this implmemtation, the thread class has become a handle class that holds a reference-counted pointer to a thread_data class. When a thread class is created, it gets access to the thread_data class for the thread using a global static thread_specific_ptr. In the scenario you outline above, when a thread object created on Thread B tries to access its thread data through this thread_specific_ptr, it will get the thread data for thread A, which is a Bad Thing.
but Thread A's won't be collected until after Thread B has exited (and another thread attempts to create thread-specific data - causing lazy cleanup).
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.
Yes, but that's still forcing the user to use a "special" dll just for that purpose.
Not necessarily. If the user's code is in a dll, its own dllmain could be used; or the dllmain of the "pseudo dll" that is created on the fly could be used. Mike