On Tue Nov 15 20:31:00 2022 +0000, Zebediah Figura wrote:
I guess, but it depends on the fact that "read_result" is zero-initialized and never written, which seems non-obvious and a little fragile. In fact, I think it can already break if a stream was selected and then later becomes deselected, even if the filter was stopped in between. Checking "stream->read_requested" would be more obvious but I think still broken for the same reasons (but simple enough to fix.) Note that if you do that then read_result becomes superfluous and doesn't really need to be stored anywhere.
`read_result` is written to E_PENDING whenever a read is requested. Every requested read will eventually be completed, writing the result to `read_result`, either `S_OK` or an error.
If a stream was selected and a read requested to it, then later becomes deselected, we will consider it a valid thread wrt sample delivery until it completes its read and writes to `read_result`. It may complete it with a sample if the deselection happened late, or with an error if its read was interrupted.
`read_requested` is a one way flag to tell reader to start reading. It needs to be reset before the `GetNextSample` call, and checked again on return to correctly synchronize flush and read requests from the callback thread, for instance when seeking.