On Fri Nov 18 10:46:02 2022 +0000, Giovanni Mascellani wrote:
I agree it's a bit weird, but `wg_parser_stream_get_buffer()` can block, and if the lock is kept basically no other media source or media stream method can be called. In general the lock shouldn't be kept for long, but in some cases it could. For example, we could be reading from a slow network. I agree at this point it's still unsafe, but that's fixed in a later patch ("winegstreamer: Synchronize media source async commands and shutdown.").
Possibly. On the other hand, we don't support interrupting such waits, and the only function that's plausibly going to be called at the same time is `wg_parser_stream_get_buffer()` from another thread. And because buffering is done asynchronously internally, I don't think it's going to make a difference in terms of timing if the two calls hold a mutex or not. (E.g. if it takes 20 ms to buffer a sample per stream, the first call will hold the mutex for 20 ms, but the second call should block on the first and then return almost immediately.)
Granted, that's an armchair analysis, and there could be timing problems I'm not anticipating.