|
|
Threads-Devel : |
Subject: Re: [Threads-devel] link problem: _pRawDllMain conflict issue
From: Ben (avhacker_at_[hidden])
Date: 2009-06-22 12:00:10
2009/6/22 Anthony Williams <anthony_at_[hidden]>
> 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.
>>
>
> I will take your word for this, but I don't understand: if you build them
> inhouse, why can't you sign them?
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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/threads-devel
>