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...