I have verified that on WinXP SP3 a one handle leak happens for each
time the following sequence of code is executed.
handle = LoadLibrary("iphlpapi.dll");
GetNetworkParamsFunc = GetProcAddress (handle, "GetNetworkParams");
res = (*GetNetworkParamsFunc) (fi, &size);
Since on long running processes executing this loop many times will
lead to a huge number of handles being leaked, and this would be
unacceptable for a server it could be the reason for officially only
making available the bug-free iphlpapi.dll for W2K3. But this is pure
speculation on my part.
Funny enough the W2K iphlpapi.dll does not suffer from this handle leak.
Back to c-ares stuff..
Static linking of iphlpapi.lib will break many Win32 cross-compilation
c-ares setups, besides dropping oldest Windows support from c-ares.
Implementing an ares_win32_init() funtion that would load iphlpapi.dll
and advapi32.dll and setup function pointers for GetNetworkParams()
and SystemFunction036() for further use in get_iphlpapi_dns_info() and
randomize_key(), and implementing also an ares_win32_cleanup() funtion
that unloads iphlpapi.dll and advapi32.dll should result in a
performance improvement over what is currently been done in c-ares and
_aditionally_ it would solve the iphlpapi handle leak.
The introduction of these two functions would represent that well
behaved apps, or libs, should get these new Win32 function calls
compiled conditionally depending on the value of ARES_VERSION only for
Instead of directly exposing ares_win32_init() and
ares_win32_cleanup() in the public c-ares API, these could be private
to c-ares and we could expose others like ares_global_init() and
ares_global_cleanup() that would be platform agnostic.
I don't think we would need a parameter for ares_global_init(), but
providing one from the very beginning will prevent some breakage if
the need further arises.
This is very close, nearly equal, as things are handled in libcurl and
The drawback of this solution is ABI breakage for Win32 platforms.
Other systems would not be affected since including or omitting the
ares_global_init() and ares_global_cleanup() functions will represent
no change at all for them.
If this is the way to go, should this be included in current cvs
c-ares version or once next release takes place?
Received on 2009-05-16