Dear c-ares developers,
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).
>> ares_library_init:
This function is not thread safe. You have to call it once the program has started, but this call must be done before the program starts any other thread. This is required to avoid potential race conditions in library initialization, and also due to the fact that ares_library_init(3) might call functions from other libraries that are thread unsafe, and could conflict with any other thread that is already using these other libraries.
<<
>> ares_library_cleanup:
This function is not thread safe. You have to call it once the program is about to terminate, but this call must be done once the program has terminated every single thread that it could have initiated. This is required to avoid potential race conditions in library deinitialization, and also due to the fact that ares_library_cleanup(3) might call functions from other libraries that are thread unsafe, and could conflict with any other thread that is already using these other libraries.
<<
Many thanks,
Vitaly
Received on 2010-07-07