On Wed Apr 9 22:50:49 2025 +0000, Elizabeth Figura wrote:
... getting rid of the read thread would basically mean a full
redesign of wg_parser. It really wouldn't, as I tried to say over and over again, and this is why the entire fiasco was so frustrating. Nobody listened.
Unless you think there's a way to use `wg_parser` without the read thread?
It would require modification, but less than you might think. There's nothing preventing you from calling wg_parser_get_next_read_offset / wg_parser_push_data from the same thread that you're pulling samples from. The reason this doesn't work is that both wg_parser_get_next_read_offset and wg_parser_stream_get_buffer are currently blocking calls, and since both can be triggered by asynchronous work, you don't know whether or not you need more data or not. In order to fix this, you'd probably want to modify wg_parser_stream_get_buffer() to allow being interrupted if a read request comes in, whereupon it'd probably return a special status to signify that.
Not sure exactly how you would suggest using a PE-side mutex to
implement this. One way I tried couldn't account for `WMSyncReader` method being called concurrently. This MR makes sure that the read thread can read iff there is >= 1 threads inside `WMSyncReader` methods. Sorry, I probably wasn't clear enough. The idea would not be to use the mutex as a normal mutex, but basically invert it. I guess you'd actually have to do it with a semaphore or auto-reset event, though, since you don't want to tie it to any specific thread. Basically, you'd want the semaphore to start out in acquired state; acquire the semaphore in the read thread before doing any read applications and release it afterwards; and *release* the semaphore when entering a function like GetNextSample() and acquire it when exiting.
@zfigura Hi I updated this to use a semaphore like you suggested. Is this enough to get this MR merged?
I feel I kinda got caught in the middle of a debate :sweat_smile:. If you insist the read thread has to go, then I'd like to wait for a consensus of what the future of gstreamer in wine is. And in that case I hope @rbernon can chime in as well.