-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-02-26 20:13, schrieb Max TenEyck Woodbury:
In particular, user call back functions are being called in several places with this mutex held. If the callback starts another thread to do something graphical where the thread needs the mutex, and then waits for the thread to finish, both threads will hang until the mutex times out. There are also places where a function that takes out the mutex is called with the mutex already held.
ddraw calls application-provided callback functions. A long time ago I did some testing on Windows, and it also uses a dll-global lock for ddraw and keeps it held when calling those callbacks. So we're doing the right thing here.
In case of d3d8/9, there are in theory the Resource's SetPrivateData, GetPrivateData and FreePrivateData functions that can call application code, specificly an IUnknown's AddRef and Release function. I have never tested how those behave wrt the dll lock. This thing can also be used to write a black-box test to see at which granularity Windows does d3d8/9 synchronization.
Switching to another terminal window and back again sometimes breaks these deadlocks.
That seems wrong, unless we're accidentally holding those locks while sending window messages.