[whatwg] Real-time thread support for workers

[Janusz Majnert]

> Yes. Especially in mobile devices it makes a world of difference when for
> example on a single-core phone you have an audio app in the foreground, and
> a Twitter client in the background. If the Twitter client decides to update
> its content, the audio is most likely to glitch and this is most likely not
> the way the user wanted it to go.

Sorry for cutting in, but if I understand correctly, in this use case we have
two separate web applications, right?
 - If so, the scheduling should be left to the UA or even the operating
   system (depending on the architecture). IMHO allowing JS code to elevate
   "niceness" of the thread/process on the operating system level is not
   a good idea.
 - If not, we are then talking about a single web application that has two
   contexts, and IMHO the programmer should make sure such problems don't
   come up.

In either case the UA has the ability to throttle the web applications'
threads so that the real time content is not disturbed.

Best regards,
Janusz Majnert