Re: Leaked handles on Windows

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.

-- 
-=[Yang]=-