Jens Theisen wrote:
Sohail wrote:
Might be related?
Yes, that's what I found as well.
Jens
It seems like the same issue to me. I could not find in that thread if a "solution" was found. Don't get me wrong, I agree boost::thread does not really leak memory and I agree the OS "should" free the critical section but I can see how an app that must regularly create separate sub-processes running in, let's say, Win98, could cause problems. According to the thread above (and looking at the boost::thread code) the "possible resource leak" is due to a mutex created in tss_hooks.cpp in Windows platforms. This mutex seems to be used to synchronize the functions at_thread_exit, on_process_enter, on_process_exit, on_thread_enter and on_thread_exit, also defined in tss_hooks.cpp. I am not sure what is the purpose of those functions but they seem to be related to thread exit handlers and the implementation of thread_specific_ptr. Again, I don't think this mutex allocation is a problem but I wonder if there should be a way for users to disable this behavior if they don't plan to use thread_specific_ptr. Besides getting rid of the anoying resource leak report given by some tools when just creating threads, disabling that mutex would mean threads would exit a little faster because there would be no mutex locking on thread exit (on_thread_exit function is called when every thread exits). Anyway, just an idea, I may be overlooking something. -delfin