Roland Schwarz
gast128 wrote:
Downloading and using the 1.32 version was probably not such a good idea...
Why do you think so? I am facing a similar situation in that I will need to rewrite parts of my code
This was a joke: the c++ standard chose for stability and therefore ended up in weird constructs. So I think boost follows the path in fixing/refactor things, instead of sticking to (incorrect) old versions. This has my preference too.
Granted. However as I have found out using the MSVC memory leak detection can be tricky at times. One usually must be careful not to generate false alarms. Which detection system do you use? (Sidebar: wouldn't a boost::memory_debug lib be desirable?) E.g. when inside MFC you cannot be sure when the detection code actually triggers, since it is called from within a destructor of a global object. If you are also allocating dynamic memory from a global constructor the leak is reported depending on the order of constructor calls. (Don't know why MS deactivated the CRT detection when using MFC....) See my other response. I guess we both noticed the same, but this can be circumvented by loading the mfc71d.dll as one of the first (e.g. after ntdll.dll).
I guess it wouldn't be difficult to resolve this one, on process exit it
be deallocated.
I guess you are refering to the (documented) leak in tss.cpp, aren't you?
// Intentional memory "leak" // This is the only way to ensure the mutex in the global data // structure is available when cleanup handlers are run, since the // execution order of cleanup handlers is unspecified on any platform // with regards to C++ destructor ordering rules. tss_data = temp.release();
Getting rid of it however is not as trivial as it might seem at first glance, since the TLS code is able to clean up even when used from non boost::threads. There is also a yet to be discussed issue what should happen when the main thread exits but a user thread is still running. (When you have a look at pthreads, this is quite legal.) And what is "process exit" when speaking about global ctors/dtors?
And yes I am aware of the (phoenix) singleton discussions in Alexandrescu/Meyers, but really this kind of reinit of singletons after atexit calls won't happen too much.
Sorry I am not aware of this discussions, could you give me a short overview? I suspect the problem is similar to when using the CRT together with the native CreateThread API. In this case you are also introducing an unavoidable memory leak, where the CRT's TLS doesn't get deallocated. (Or occasionally will be reallocated.) Alexandrescu discusses in his book 'Modern C++ Design' singletons and the
can problem of destroying it (chapter 6). There can be a problem if the singletons are called again in exit code. While this can be a problem, I guess in practice it will not happen often, or can be circumvented. The m-leak I noticed is in tss_hooks.cpp, in fct 'init_threadmon_mutex'.
But I agree it _is_ ugly and it should be removed for any reason, no matter.
It would be nice. For the moment I will discourage the use of the thread libraries because of this issue, although it is a nice library. Wkr, me