Today, if media_source_Shutdown is called around the same time as a work item is put on the async_commands_queue, we end up in a deadlock if Shutdown enters media source's cs first, as it waits for the queue's callback to finish, which, in turn, waits for the object's cs to be released.
To avoid this leave the cs, before unlocking the workqueue, to let any callback on the queue finish running.
Signed-off-by: Bernhard Kölbl bkoelbl@codeweavers.com
Blocks !3351
From: Bernhard Kölbl bkoelbl@codeweavers.com
Today, if media_source_Shutdown is called around the same time as a work item is put on the async_commands_queue, we end up in a deadlock if Shutdown enters media source's cs first, as it waits for the queue's callback to finish, which, in turn, waits for the object's cs to be released.
To avoid this leave the cs, before unlocking the workqueue, to let any callback on the queue finish running.
Signed-off-by: Bernhard Kölbl bkoelbl@codeweavers.com --- dlls/winegstreamer/media_source.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/dlls/winegstreamer/media_source.c b/dlls/winegstreamer/media_source.c index e1e64fc7f98..e22ead19994 100644 --- a/dlls/winegstreamer/media_source.c +++ b/dlls/winegstreamer/media_source.c @@ -1570,6 +1570,8 @@ static HRESULT WINAPI media_source_Shutdown(IMFMediaSource *iface) free(source->descriptors); free(source->streams);
+ LeaveCriticalSection(&source->cs); + MFUnlockWorkQueue(source->async_commands_queue);
LeaveCriticalSection(&source->cs);