2009/6/22 Anthony Williams
<anthony@justsoftwaresolutions.co.uk>
Ben wrote:
I can't, however, use this version because all exe/DLL files shipped from our company need a digital sign to pass Vista/Win7 logo. Since boost is released in the form of source codes, the DLL files will be built by ourselves. But we can't sign the Boost DLL files since they are not made by our company.
Due to our legal policy, we don't sign the DLLs which are not our own software. I know that it's weird because we do sign to the DLLs that statically link with Boost libs. The DLLs, of course, contains Boost codes are still signed. But it's legal policy. What can I say?
BTW, in the point of view from our programmers, we like static Boost libraries more. Not to mention that there's (was?) a bug about auto linking if we want to use Boost DLLs.
Ok, the DLL version can't meet our requirement. Will the _pRawDllMain conflict issue be resolved in the next version?
It won't be in 1.40.0. I will endeavour to get the fix in sometime soon, though.
I didn't trace deep into the source codes. Is it really necessary to use thread-locals?
By the way, we are now using Boost 1.35.0 and found that the TLSFree() is not called and caused a resource link that make us failed to pass the Vista/Win7 logo test. So we tried Boost 1.39.0 and encountered the link conflict issue.
How are you using boost.thread? This should only be a problem if you are linking statically against boost.thread from a DLL. If you do this, you need to be aware that thread-locals are thus isolated to that DLL, and are not accessible from other DLLs, even on the same thread.
TlsFree is only called on process shut-down. If you can ensure that on_process_exit from boost/thread/detail/tss_hooks.hpp is called when the DLL is unloaded then you can patch libs/thread/src/win32/tss_pe.cpp to remove the use of _pRawDllMain.
If you are linking boost.thread directly into the EXE then you can remove this use of _pRawDllMain anyway with no averse consequences.
Unfortunately, we are linking statically against boost.thread from a DLL which use MFC. And we don't want to modify any source code of Boost especially when we need to sync the changes between hundreds of programers.
I don't think that calling TlsFree() in on_process_exit is a good idea because it should be called when the DLL unloads. If the DLL is loaded/unloaded dynamically by LoadLibrary()/FreeLibrary(), the timing when DLL unloads will be different from the timing when process exists.
Since the Boost library doesn't meet our requirement and we don't want to modify our codes that uses Boost.Thread, my quick solution is to implement these facilities that we had used in Boost.Thread. It's lucky that we only use some simple tools: thread creation/join, recursive_mutex(and it's scoped_lock), condition. So I implement them and it looks like we can avoid this leak/link issue.
Anthony
--
Author of C++ Concurrency in Action | http://www.manning.com/williams
just::thread C++0x thread library | http://www.stdthread.co.uk
Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
_______________________________________________
threads-devel mailing list
threads-devel@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/threads-devel