Use of wined3d_mutex?

[Max Woodbury]

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