[whatwg] Real-time thread support for workers

[Ian Hickson]

On Thu, 9 Aug 2012, Jussi Kalliokoski wrote:
> 
> On W3C AudioWG we're currently discussing the possibility of having web 
> workers that run in a priority/RT thread. This would be highly useful 
> for example to keep audio from glitching even under high CPU stress.
> 
> Thoughts? Is there a big blocker for this that I'm not thinking about or 
> has it just not been discussed yet? (I tried to search for it, but 
> didn't find anything)

I think it's impractical to give Web authors this kind of control. User 
agents should be able to increase the priority of threads, or notice a 
thread is being used for audio and start limiting its per-slice CPU but 
increasing the frequency of its slices, but that should be up to the UA, 
we can't possibly let Web authors control this, IMHO.


On Thu, 9 Aug 2012, Jussi Kalliokoski wrote:
> 
> Yes, this is something I'm worried about as well. But prior work in 
> native applications suggests that high priority threads are hardly ever 
> abused like that.

Native apps and Web apps aren't comparable. Native apps that the user has 
decided to install also don't arbitrarily reformat the user's disk or 
install key loggers, but I hope you agree that we couldn't let Web authors 
do those things.

The difference between native apps and Web apps is that users implicitly 
trust native app authors, and therefore are (supposed to be) careful about 
what software they install. However, on the Web, users do not have to be 
(anywhere near as) careful, and so they follow arbitrary links. Trusted 
sites get hijacked by hostile code, users get phished to hostile sites, 
trolls point users on social networks at hostile sites. Yet, when all is 
working as intended (i.e. modulo security bugs), the user is not at risk 
of their machine being taken down.

If we allow sites to use 100% CPU on a realtime thread, then this changes, 
because untrusted hostile sites actually _can_ cause harm.

The way the Web platform normally gets around this is by having the Web 
author describe to the UA what the author wants, declaratively, and then 
having the UA take care of it without running author code. This allows the 
UA to make sure it can't be abused, while still having good performance or 
security or whatnot. In the case of Web audio, the way to get sub-80ms 
latency would be say "when this happens (a click, a collision), do this 
(a change in the music, a sound effect)". This is non-trivial to specify, 
but wouldn't run the risk of hostile sites harming the user.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'