Re: [Boost-users] thread library
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Jens Theisen Sent: Tuesday, January 24, 2006 10:33 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] thread library
monade wrote:
Ok, it may be no memory leak, but only a harmless resource leak (as Alexandrescu calls it in his singleton chapter), but I don't like it anyway (my own singletons does not leak).
If there would be a delete in the destructor, you would not gain anything: The destructor of a singleton is conceptually called on program termination and that's also where all resources are freed by the operating system anyway. So it's perfectly reasonable to not free it.
I could've sworn we just went through this a few months back. Perhaps its time to put a comment that links to the appropriate boost mailing thread. http://lists.boost.org/boost-users/2005/08/13538.php Might be related?
Sohail wrote:
Might be related?
Yes, that's what I found as well. Jens
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
participants (3)
-
Delfin Rojas -
jth01＠arcor.de -
Sohail Somani