[isolated-workers] The event loop infrastructure of HTML is too tied to a normal processing model

[padenot]

We need to decouple the event loop data structure and execution model from when
it runs.

IsolatedWorkers are going to be used in a variety of contexts. They will be
non-realtime (for example, an IsolatedWorker for computing some layout),
soft-realtime (an IsolatedWorker doing work on each frame of a video),
hard-realtime (an IsolatedWorker for processing audio on a low latency thread).

In some contexts, the thread on which the code runs is idle most of the time,
and gets woken up, does some work, and goes to sleep again, so it is not
possible to implement HTML's event loop:

An event loop must continually run through the following steps for as long as it exists:

I think we need to allow the event loop to specifically go to sleep if no event
is present instead of busy waiting. We also need to allow not running a task
immediately when when a task is queued. Consider the following scenarii:

• An IsolatedWorker may want to run on each compositing operation. Compositing
  operations are ideally synchronized to the refresh of the display, or the GPU
  or whatever, depending on hardware, software, and how old it is. Anyways, a
  thread can be blocked and you're unable to process more events, until it's
  time to re-composite.
• An IsolatedWorker may want to run a script on each new frame of an
  HTMLVideoElement, so that it can process it. Of course, you'd only run script
  when a new frame is decoded and available.
• An IsolatedWorker may be part of a Web Audio graph, and may want to run as
  part of the graph of AudioNodes. In this context, you can only run script when
  the audio callback fires, and you cannot run code when waiting for it to fire.

In those cases, the HTML definition of the event loop cannot be implemented.

[domenic]

Maybe I am misunderstanding, but this sounds like an implementation concern, not a spec concern. For example, I don't believe there is any author-observable difference between busy-looping, and sleeping while there are no tasks.

[FremyCompany]

+1 to @domenic here

[rocallahan]

I think it's a matter of what APIs are provided in each flavour of IsolatedWorker.

E.g. for AudioWorkers we might decide that code can only run on the worker when called by the Web Audio processing logic. In that case we have to make sure there are no APIs that cause code to run on that worker at other times (e.g. postMessage or timers).

[bfgeek]

I added a note to the spec that this is really just an implementation issues, and the event loops aren't expected to be run continuously.