- From: Ian Hickson <ian@hixie.ch>
- Date: Sat, 27 Oct 2012 00:14:08 +0000 (UTC)
- To: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, David Bruant <bruant.d@gmail.com>, Janusz Majnert <jmajnert@gmail.com>, Glenn Maynard <glenn@zewt.org>
- Cc: whatwg@whatwg.org, Jonas Sicking <jonas@sicking.cc>
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. `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 27 October 2012 00:14:36 UTC