[PATCH] winegstreamer: Do not block forever if EOS races with command queue.

[Nikolay Sivov]

On 2/8/22 22:44, Giovanni Mascellani wrote:
> Hi,
>
> Il 08/02/22 18:50, Zebediah Figura ha scritto:
>> I'm having a hard time understanding the race here. Can 
>> wait_on_sample() be called multiple times concurrently for the same 
>> stream? If not I don't see how it can race with itself.
>
> Consider this flow:
>  * RequestSample() is called: it checks that the stream is not EOS and 
> queues SOURCE_ASYNC_REQUEST_SAMPLE;
>  * while SOURCE_ASYNC_REQUEST_SAMPLE is in the queue, RequestSample() 
> is called again, and another SOURCE_ASYNC_REQUEST_SAMPLE is queued;
>  * the first SOURCE_ASYNC_REQUEST_SAMPLE is executed and 
> wait_on_sample() is called; wg_parser_stream_get_event() happens to 
> find stream->event of type WG_PARSER_EVENT_EOS; it returns that event 
> and reset the event to WG_PARSER_EVENT_NONE; consequently 
> wait_on_sample() issues a MEEndOfStream event;
>  * the second SOURCE_ASYNC_REQUEST_SAMPLE is executed and 
> wait_on_sample() is called; wg_parser_stream_get_event() sees the 
> stream event set to WG_PARSER_EVENT_NONE, and it will never change, 
> therefore it waits forever.
>
> The problem is that the EOS condition must be rechecked inside 
> wh_parser_stream_get_event(), because last time it was checked (in 
> RequestSample()) might be out-of-date.
>
> Does this make sense?

I think this will benefit from some locking, protecting source state.

>
> Thanks, Giovanni.
>