On Fri Nov 18 20:32:47 2022 +0000, Zebediah Figura wrote:
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.
Yeah, I am not very convinced. For example, I think it is totally plausible that methods like `GetCharacteristics`, `GetRate`, `SetRate` are often called on a time-sensitive thread, on the assumption that on Windows they're nearly instantaneous. Having them waiting on a lock that might wait for disk (or even network) access doesn't seem a good idea.
The API general idea seems to be that calls are usually very quick, and all the heavy lifting is done in background threads. I think we should respect this design point and avoid having calls wait on the background thread (except for `Shutdown()`, where this can't be avoided and it's a special call anyway; it could also be avoided, and that was my first solution indeed, but then we have to modify the WG parser so that the wait can be interrupted).