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

[Zebediah Figura]

On 2/8/22 13: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?
> 

Yes, thanks for clarifying.

In that case it seems sufficient to check stream->eos in 
wait_on_sample(). There should be no need to modify the Unix side here.

Somewhat out of curiosity, have you actually observed both 
MF_E_END_OF_STREAM from RequestSample() and MEError with 
MF_E_END_OF_STREAM from the same media source on Windows? It seems 
awkward that we're reporting the same condition in two different ways 
like that, but if that's the way Windows behaves...