On 02/27/2014 03:10 AM, Stefan Dösinger wrote:
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.
Thank you for the information. That means I can ignore that issue.
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.
Uh, OK. (More information than I can handle at the moment. Maybe later...)
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.
With the time-out in place, it is hard to tell if it is still a problem, but it used to happen irregularly. It seemed to be something racy. It showed up with one batch of patches and then disappear after a couple more sets. Whatever it is, it is a really old problem.
IIRC it was more of a problem with ddraw4 and ddraw7 than it was with the earlier interfaces...
max