[PATCH v6 0/3] MR302: winegstreamer: Some wg_transform H264 fixes for Mortal Kombat 11 and Yakuza 4.

[Rémi Bernon (@rbernon)]

> I understand that adding more locks increases the mental burden, but I 
> think this is worse—sure, we're "reusing" a lock that was going to be 
> created anyway, but it's still effectively introducing another lock, 
> plus now this requires us to understand when GStreamer is going to 
> implicitly take that lock.

Regarding the lock, it's not really about the mental burden but about
actual deadlock situations. It's happening already in many cases in
winegstreamer and I don't want to make it worse.

Adding a new lock to the wg_transform is just calling for trouble. It
may be fine for this very case, to guard the output_wg_sample pointer
updates, and as long as it stays used for this only, but having a lock
in the wg_transform makes it appealing to use it for guarding more
things in the future. I don't want to introduce that opportunity.

The interlocked pointer exchange is guaranteeing the same thing as an
explicit lock, except that it cannot cause any deadlock. I've made an
update to the MR, keeping it as I think it's the best solution, but
moving the sample size check to the allocator, to also simplify the
wg_transform callback.

Retrospectively, I agree that using the GStreamer object lock for the
allocator locking is a bit risky as well, so I'll leave this aside too.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/302#note_3322