Use of wined3d_mutex?
Max Woodbury
mtewoodbury at gmail.com
Thu Feb 27 10:00:04 CST 2014
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
More information about the wine-devel
mailing list