Fixed another bug in the thread_specific_data object. It should now

work right regardless of the destruction order of the relevant global
bits of state hanging around.

--HG--
extra : convert_revision : svn%3Afdd8eb12-d10e-0410-9acb-85c331704f74/trunk%402493
This commit is contained in:
Davis King 2008-08-22 16:01:47 +00:00
parent d9462674a9
commit f841ccb543
1 changed files with 21 additions and 2 deletions

View File

@ -26,11 +26,25 @@ namespace dlib
public:
thread_specific_data (
){}
)
{
thread_end_handler_calls_left = 0;
}
~thread_specific_data (
)
{
// We should only call the unregister_thread_end_handler function if there are
// some outstanding callbacks we expect to get. Otherwise lets avoid calling it
// since the dlib state that maintains the registered thread end handlers may have
// been destructed already (since the program might be in the process of terminating).
bool call_unregister = false;
m.lock();
if (thread_end_handler_calls_left > 0)
call_unregister = true;
m.unlock();
if (call_unregister)
unregister_thread_end_handler(const_cast<thread_specific_data&>(*this),&thread_specific_data::thread_end_handler);
auto_mutex M(m);
@ -74,7 +88,10 @@ namespace dlib
in_tree = true;
if (is_dlib_thread(id))
{
register_thread_end_handler(const_cast<thread_specific_data&>(*this),&thread_specific_data::thread_end_handler);
++thread_end_handler_calls_left;
}
}
catch (...)
{
@ -97,6 +114,7 @@ namespace dlib
thread_id_type junk;
T* item;
auto_mutex M(m);
--thread_end_handler_calls_left;
if (items[id])
{
items.remove(id,junk,item);
@ -106,6 +124,7 @@ namespace dlib
mutable typename binary_search_tree<thread_id_type,T*>::kernel_2a items;
mutex m;
mutable long thread_end_handler_calls_left;
// restricted functions
thread_specific_data(thread_specific_data&); // copy constructor