Re: Leaked handles on Windows

Yang Tse wrote:
> 2009/5/18, Vlad Dinulescu wrote:
>> Steinar H. Gunderson wrote:
>>> 2009/5/18 Daniel Stenberg <daniel_at_haxx.se>:
>>>> I'm sorry but I don't understand. How do you propose we fix this problem
>>>> without breaking the ABI?
>>> Can't you just load the library the first time you need it, and then
>>> store the handle forever? (Just make sure to use Windows' equivalent
>>> of pthread_once(), so you're thread-safe.)
>>>
>>> /* Steinar */
>> That's also a good solution (in my opinion).
>
> There's a couple of issues with the approach of not doing the explicit
> calls to ares_library_init() and ares_library_cleanup() and simply
> relying on c-ares functions doing the lazy-initialization calling
> ares_library_init().
>
> I'll first comment simply for Win32 target builds...
>
> The most similar function to pthread_once() on Win32 is
> InitOnceExecuteOnce() but is only available in kernel32 for WinVista
> and later.
>
> So we would have to fall back to an implementation that uses a Mutex
> and a volatile variable to prevent the mutex from slowing this down to
> death.
>
> But in order to avoid race conditions the volatile variable mentioned
> above should be used with InterlockedCompareExchange() which is only
> available in kernel32 for Win98 and later.
>
> So, even doing our best, on Win95 this would result in a race
> condition when not calling ares_library_init() explicitly.
>
> For the rest of Windows versions the volatile variable checking would
> mean that those programs using c-ares, no matter if they do the call
> to ares_library_init() or rely on lazy-initialization, will suffer a
> performance penalty due to cpu pipeline flushing each time ares_init()
> is called.
>
> The above would not be possible to fix unless all the lazy
> initialization code is removed from c-ares. Once the Win32 programs
> heavily using ares_init() slow to a crawl, many would require a fix,
> no matter if it breaks API, ABI or whatever.
>

Yes, you are right. So just linking against iphlpapi.lib seems to be
the best way after all.

-- 
Best regards,
Vlad Dinulescu