On Tue, 13 Jul 2010, Vitaly Kruglikov wrote:
> With respect to "These functions are declared non-treadsafe as this is very
> common and typical by initialization/cleanup mechanisms. We can see this in
> lots of other libs.":
>
> It's true that several mainstream libs do this, including openssl and
> libcurl, but this unfortunately makes those, otherwise very useful libs,
> either unusable or not safely-usable in multi-threaded apps with plug-ins,
> or forces implementations to break down their abstraction mechanisms (thus
> forcing the problem to be propagated by users). This is one of those
> problems that once done by a shared module, it ends up forcing a propagation
> of that problem by all outer layers. I am told that there is already a good
> discussion going on about this type of problem on the openssl forum, as
> engineers have realized the limitations of this practice.
Yes. libcurl for example does it only because its underlying libs do it, like
said OpenSSL...
> Before investing effort in a patch, I'd like to explore our options a little
> bit. A mechanism that readily comes to mind is to make use of the atomic
> library constructor/destructor to initialize the library's dependencies.
> However, the c-ares doc states that doing so on Windows may cause a
> deadlock.
What "atomic library constructor/destructor" are you talking about here?
> Is this a common problem for Windows and Linux/Unix or just Windows?
Right now the only global init that is going on in ares_library_init() is
Window-specific...
> What is the specific logic that would cause a deadlock on Windows if
> executed from a dll's "constructor"?
I know next to nothing about Windows, so I can't answer that!
-- / daniel.haxx.seReceived on 2010-07-13