On 5/24/22 02:06, Rémi Bernon (@rbernon) wrote:
On Tue May 24 06:14:02 2022 +0000, Rémi Bernon wrote:
InterlockedOr() looks suspicious. If we're going to be thread safe
(and
we should) we should just take the filter lock around IFileSourceFilter::Load(). [It's already implicitly taken in the get_pin() callback.]
I was wary of locking because WM reader callbacks are done while holding WM reader lock, and prevent any concurrent call to other WM reader methods. I had some patches to leave the lock when calling the callbacks but I'm not sure it's a good way to go.
Hmm, some brief tests suggest that wmvcore should not deadlock when callbacks block. (For that matter, there's no clear indication that wmvcore is thread-safe to begin with...)
It's probably not worth worrying about thread safety at the moment.
[It's already implicitly taken in the get_pin() callback.]
Is it really? I don't see it anywhere and it looks to me that `filter->ops->filter_get_pin` is called in many places unguarded, like `enum_pins_Clone`, `enum_pins_Next`, `filter_EnumPins`, etc...
Okay, I lied, it's not. It *should* be, but that's a job for another time...