Boost logo

Boost Users :

From: Delfin Rojas (drojas_at_[hidden])
Date: 2006-01-24 18:18:03


Jens Theisen wrote:
> Sohail wrote:
>
>> http://lists.boost.org/boost-users/2005/08/13538.php
>
>> 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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net