Re: Huge problem with ares_library_init() and ares_library_cleanup()

>>>>>>
Message: 2
Date: Mon, 12 Jul 2010 18:08:18 +0200 (CEST)
From: Daniel Stenberg <daniel_at_haxx.se>
To: c-ares hacking <c-ares_at_cool.haxx.se>
Subject: Re: Huge problem with ares_library_init() and
        ares_library_cleanup()
Message-ID: <alpine.DEB.2.00.1007121806340.6011_at_tvnag.unkk.fr>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Wed, 7 Jul 2010, Vitaly Kruglikov wrote:

> prior to upgrading to the newer version of c-ares, I consulted c-ares
> documentation and discovered two new functions that pose a huge problem to
> users of the library: ares_library_init() and ares_library_cleanup().
>
> Both functions are defined as 'not thread-safe' and have to be executed
> before starting any other threads (ares_library_init) and after terminating
> all threads (ares_library_cleanup).
>
> This makes it impossibly to use the c-ares library safely by plug-ins in a
> multi-threaded process. Since a multi-threaded process that employs
> plug-ins (e.g., dynamically-loaded shared libraries) doesn't know which
> libraries will be used by dynamically-discovered/dynamically-loaded
> plug-ins, there is no safe way to initialize c-ares.
>
> Please, please provide a thread-safe, re-entrant initialization/cleanup
> mechanism that allows this incredibly useful library to be used under the
> above-described, fairly common circumstances (without forcing the overhead
> of static linking).

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.

We're of course always interested in improving the lib so feel free to bring
on your code/patches and we'll discuss them!

--
  / daniel.haxx.se
<<<<
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.
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.  Is this a common problem for Windows and Linux/Unix or just Windows?  What is the specific logic that would cause a deadlock on Windows if executed from a dll's "constructor"?
Thank you,
Vitaly