Hello,

Did you test your code on Windows XP 32-bit version to verify it is a
windows 64-bit bug? If you would see the same problem on Win32, then
this would most likely point to your application or something in the
build process.

If it is Win64 only then, I don't have much of an idea as we run only
on Win32 on our end.

Cheers,

Matt Veenstra
tribalmedia
415.504.3916

On Oct 24, 2007, at 10:03 AM, George Woltman wrote:

>
> I'm using 64-bit Windows XP and MS Visual Studio 2005. I've run
> into the following deadlock
> condition and don't really know what to do about it.
>
> My program does all communication in a separate thread. It calls
> curl_easy_perform, which calls
> the curl resolver. This creates a thread. The C runtime library
> implementation of _beginthreadex
> calls GetModuleHandle ("KERNEL32.DLL"). If my main message
> processing thread happens to
> call LoadIcon or SetIcon at this time, then BAM - I've deadlocked.
>
> I don't fully understand what is causing the deadlock. Google
> reveals some articles about the
> dangers of doing any real work in DllMain because the OS has
> acquired a lock. Maybe
> KERNEL32.DLL's DllMain is initializing some thread-local storage
> and tries to acquire Kernel
> locks that LoadIcon or SetIcon is also trying to get.
>
> I know this is more of an OS bug or a C runtime library bug.
> Questions:
> 1) Can anyone explain in better detail the cause of the deadlock
> and/or suggest a workaround?
> 2) Is there a way to have the resolver not spawn a thread or cache
> and reuse threads?
>
Received on 2007-10-24