Question

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?

Answer 1

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.

Answer 2

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).

Answer 3

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?

Best Practices for Creating DLLs

Answer 4

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).

友情链接