Re: [media-source-tests] Add media-source delaying-the-load-event-flag reset test from Chromium (#3082)

I don't think it matters too much, but let me try to reformulate differently because I still don't get why events fire in any precise order. It certainly should not block anything, and seems very low priority to me.

Let's call the thread that runs the event loop `LoopThread`.

The steps defined in MSE in the [Attaching to a media element](https://w3c.github.io/media-source/#mediasource-attach) section run as part of the [resource fetch algorithm](http://www.w3.org/TR/html51/semantics-embedded-content.html#resource-fetch-algorithm). That algorithm is run *in parallel* by the [resource selection algorithm](http://www.w3.org/TR/html51/semantics-embedded-content.html#resource-selection-algorithm), which means that it runs in a separate thread independent of the event loop. Let's call that thread `FetchThread`.

Before it may fire the `load` event, the browser [spins the event loop](http://www.w3.org/TR/html51/webappapis.html#spinning-the-event-loop) until the `delaying-the-load-event-flag`. The step that waits until this condition is met also runs *in parallel*, which means it runs in another thread, again independent of the event loop. Let's call that thread `SpinThread`.

What could happen is:

1. `FetchThread` runs steps 1, 2, 3 of the MSE algorithm, resetting `delaying-the-load-event-flag` and queues a task to fire the `sourceopen` event.
2. The OS interrupts `FetchThread` and resumes `LoopThread`
3. `LoopThread` runs next task, and fires the `sourceopen` event
4. The OS then resumes `SpinThread`
5. `SpinThread` detects the reset flag and queues a task to resume the [stop parsing](http://www.w3.org/TR/html51/syntax.html#stopped) algorithm, which in turn queues a task to fire the `load` event.

In that case, the `sourceopen` event fires before `load`.

Now, I think the following could happen as well:

1. `FetchThread` runs step 1 of the MSE algorithm, resetting `delaying-the-load-event-flag`.
2. The OS interrupts `FetchThread` right after that and resumes `SpinThread`.
3. `SpinThread` detects the reset flag and queues a task to resume the [stop parsing](http://www.w3.org/TR/html51/syntax.html#stopped) algorithm.
4. The OS decides to switch to `LoopThread`
5. `LoopThread` resumes the stop parsing algorithm, which queues a task to fire the `load` event
6. `LoopThread` runs another event loop and fires the `load` event
7. The OS eventually gets back to `FetchThread`
8. `FetchThread` resumes and runs steps 2 and 3 of the MSE algorithm, queueing a task to fire the `sourceopen` event.

In that case, the `load` event fires before `sourceopen`.

What prevents any of these possibilities?

Note that I have no idea whether this applies to Chromium or to any browser implementation in practice (which may perhaps merge `FetchThread` and `SpinThread` into one single thread).

View on GitHub: https://github.com/w3c/web-platform-tests/pull/3082#issuecomment-244685105

Received on Monday, 5 September 2016 08:14:03 UTC