Let me get this out of the way up front: Creating a thread from
DllMain is not recommended. The discussion here has to do with explaining the behavior you may observe if you violate this advice.
Commenter Pete points out that "according to Usenet" creating a thread in
DllMain is supposed to deadlock, but that's not what he saw. All he saw was that the thread entry procedure was not called.
I'm going to set aside what "according to Usenet" means.
Recall how a thread starts up. When you call
CreateThread, a kernel thread object is created and scheduled. Once the thread gets a chance to run, the kernel calls all the
DllMain functions with the
DLL_THREAD_ATTACH code. Once that's done, the thread's entry point is called.
The issue with deadlocks is that all
DllMain functions are serialized. At most one
DllMain can be running at a time. Suppose a
DllMain function is running and it creates a thread. As we noted above, a kernel thread object is created and scheduled, and the first thing the thread does is notify all the DLLs with
DllMain functions are serialized, the attempt to send out the
DLL_THREAD_ATTACH notifications must wait until the current
DllMain function returns.
That's why you observe that the new thread's entry point doesn't get called until after you return from
DllMain. The new thread hasn't even made it that far; it's still working on the
DLL_THREAD_ATTACH notifications. On the other hand, there is no actual deadlock here. The new thread will get itself off the ground once everybody else has finished doing their
So what is this deadlock that Usenet talks about? If you've been following along, you should spot it easily enough.
DllMain function creates a thread and then waits for the thread to do something (e.g., waits for the thread to signal an event that says that it has finished initializing, then you've created a deadlock. The
DLL_PROCESS_ATTACH notification handler inside
DllMain is waiting for the new thread to run, but the new thread can't run until the
DllMain function returns so that it can send a new
This deadlock is much more commonly seen in
DLL_PROCESS_DETACH, where a DLL wants to shut down its worker threads and wait for them to clean up before it unloads itself. You can't wait for a thread inside
DLL_PROCESS_DETACH because that thread needs to send out the
DLL_THREAD_DETACH notifications before it exits, which it can't do until your
DLL_PROCESS_DETACH handler returns.
(It is for this thread cleanup case that the function
FreeLibraryAndExitThread was created.)