George Woltman wrote:
> 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.

There are lots of problems with DllMain, it's true.

But it seems very unlikely that calls to _beginthreadex in non-main
threads would deadlock against perfectly common functions in the main
thread. Threads creating further threads is a common and natural
operation.

Isn't the call to GetModuleHandle in _beginthreadex() itself, in the
code which is _creating_ a thread, not in the DllMain() function which
is called in the _created_ thread? Deadlock only occurs with
DllMain() which _it_ contains a call to a module function.

> 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 doubt if KERNEL32.DLL does that, but if it does, initializing
thread-local storage is one of the few things it's safe to do inside
DllMain() without deadlocking :-)

-- Jamie
Received on 2007-10-25