On Wed, Jan 11, 2012 at 01:03:56AM +0800, Dmitry Timoshkov wrote:
Andrew Eikum aeikum@codeweavers.com wrote:
So, I'm asking for insights. Should I try hard to avoid launching threads unless absolutely necessary? Is this a known deficiency in the loader, and I should do nothing? Is there some other way to work around this?
As usually first thing to do is to write some tests and investigate what Windows does/how it copes with such cases.
Some more testing just confirms that we should be able to launch threads from within a client DllMain(). I wrote a test DLL, compiled in MSVC++ 2010, which basically does (pseudocode, obviously):
DllMain(){ winmm = LoadLibrary("WinMM.dll"); wOGND = GetProcAddress(winmm, "waveOutGetNumDevs"); printf("%u\n", wOGND()); }
I then load that DLL from a (severely hacked) dsound_crosstest.exe, which does not link against dsound or winmm.
Printing the result from waveOutGetNumDevs() shows that it works (it returns 2, which is correct). Monitoring the thread count via Task Manager before and after the call shows that waveOutGetNumDevs() launches a thread, like I mentioned in the first email.
Running that dsound test in Wine to load dmtest.dll deadlocks waiting for the loader CS, just like the bugs linked in the first email.
So it appears we should be able to launch threads in DllMain() without deadlocking.
Thoughts, anyone?
Andrew