In SDL_thread.c, at line 376.
The routine SDL_CreateThreadWithStackSize creates a thread, then waits for the newly created thread to signal a semaphore. If the thread does not start (and it is not guaranteed to do so) then a deadlock occurs.
I encountered this when calling SDL_Init(SDL_INIT_JOYSTICK) during the initialisation routine of a DLL. Seemingly sensible, yet it causes the above deadlock, for the reason that
“During process startup and DLL initialization routines, new threads can be created, but they do not begin execution until DLL initialization is done for the process.”
https://docs.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-createthread
Yes, if you’re doing anything non-trivial inside DLL initialization, you’re just asking for deadlocks and other ugly bugs. This is a quite well-known issue, and it falls under the heading of “Doctor, it hurts when I do this!” / “Then don’t do that.”
Thanks for the clarification. I wasn’t making the call from the DLL’s own initialisation, rather from a callback function exported to the host process, which the host process calls “when the module is loaded”. The host API documentation is not at all clear that this should be treated as a critical area. I shall take it up with them.
Argh, yeah, they really should not be doing that. Smack them upside the head with those links I posted above. That callback should run when the module is finished loading, once all DLL loads have returned.