It seems that when a thread is created from within DllMain upon DLL_PROCESS_ATTACH it won't begin until all dll's have been loaded. Since I need to make sure the thread runs before I continue, I get a deadlock. Is there any way to force the thread to start?
views:
294answers:
4
+1
A:
No. You shouldn't call CreateThread (or any varation) from DllMain. Attempting to synchronize will result in a deadlock. What exactly are you trying to do?
Evän Vrooksövich
2009-11-06 15:36:09
Nothing wrong with calling CreateThread, but there's no way around the fact that the thread will be suspended until DllMain processing completes in the parent thread.
Ben Voigt
2010-02-06 18:32:28
+3
A:
You shouldn't be doing any API calls, especially for things like creating threads or windows, from DLLMain. Raymond Chen has written about this many times; here's one that's particularly relevant.
Ken White
2009-11-06 15:37:32
CreateThread is one of the few things you can do inside DllMain, because it's a call to kernel32 which is guaranteed to be already loaded.
Ben Voigt
2010-02-06 18:24:53
A:
You're asking for trouble if you do this. You shouldn't make any calls (directly or indirectly) to functions that are outside of your dll's (including C library calls, etc.).
If you can't change the DLL you have (e.g. you don't have source code), you might be able to get away with this if your DLL is dynamically loaded after the rest of your dependent DLL's are initialized. I wouldn't recommend this approach if you can avoid it because figuring out the dependency chain is not always trivial (e.g. if your dll causes a dependent dll to load a third one dynamically through COM or some other means).
Peter Tate
2009-11-06 15:40:25
The first paragraph here is a an over-generalization. It's perfectly fine to make calls into DLLs you know for a fact were already loaded before yours. In general and in most situations, this means KERNEL32.DLL only, which may sound like a crippling limitation, but you can use it to bootstrap your way out of this situation.
Integer Poet
2010-04-20 16:08:28
Thanks Integer Poet. That answers exactly the question I came here to solve.
Steve Rowe
2010-05-05 23:42:23
A:
What does your thread do?
If you're trying to move stuff onto a second thread to avoid restrictions on what you can do inside DllMain, tough luck. Those are not restrictions on what DllMain can do, they are restrictions on what can be done while DllMain is running (and holds the loader lock). If your thread needs to take the loader lock, it will wait until the first thread finishes using it. If your thread didn't need the loader lock I don't see why it couldn't continue immediately... but there's no such thing as a thread that doesn't need the loader lock. Windows has to send DLL_THREAD_ATTACH messages to all DLLs before your thread can start running, which means it also calls your own DllMain, and Windows protects against re-entrancy.
There's no way around this. The thread can't start until after DLL_THREAD_ATTACH processing, and that can't happen while your first thread is inside DllMain. The only possible way around it is to start a new process (which has an independent loader lock and won't block waiting for yours).
Ben Voigt
2010-02-06 18:30:29