On Tue Nov 15 21:40:55 2022 +0000, Rémi Bernon wrote:
Because this is a blocking call, which can call application callbacks, or otherwise also blocking until there's a sample ready. We want to be able to deliver samples from the callback thread, on other streams, without being blocked and without blocking the reader. There's no point in making all this asynchronous otherwise.
GetNextSample() already calls callbacks with the lock held. I.e. this is basically doing the same thing as described above. I also don't see how delivering samples can block this, or the reverse, since we drop the CS in order to deliver samples. What deadlock results from not dropping the CS here?
I would guess that AllocateForOutput() is blocking in IMemAllocator::GetBuffer(), but if that's the case, according to my reading of 2/4, we should either be inside of IWMReaderCallback::OnSample() or still holding the CS and about to call it.