[whatwg] Real-time thread support for workers
jussi.kalliokoski at gmail.com
Sun Aug 12 03:16:00 PDT 2012
On Sun, Aug 12, 2012 at 6:48 AM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Sat, Aug 11, 2012 at 3:22 PM, Jussi Kalliokoski
> <jussi.kalliokoski at gmail.com> wrote:
> > On Fri, Aug 10, 2012 at 11:07 PM, Glenn Maynard <glenn at zewt.org> wrote:
> >> On Thu, Aug 9, 2012 at 1:20 AM, Jussi Kalliokoski <
> >> jussi.kalliokoski at gmail.com> 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
> >>> example to keep audio from glitching even under high CPU stress.
> >> Realtime work is hard in a nondeterministically GC'd environment.
> >> Be careful about a flag that says "run this thread at higher priority".
> >> People will simply always set it; it makes their code run faster (at the
> >> expense of other pages' workers, who they don't care about).
> > I'm not sure what that claim is based on, in native applications the
> > process priority hardly ever (haven't seen once, actually) gets abused.
> > only place where high priority really makes sense outside the main thread
> > (which we won't allow) is time-critical threads, such as audio processing
> > or a physics engine.
> The security model for native applications is different from the
> security model for the web.
> When running a native application on most contemporary operating
> systems, you are trusting that application to behave well. I.e. you
> trust it to not read private data from your computer and send it to a
> remote location. You trust it to not use system resources to send spam
> emails. You trust it to not install backdoors and hand control over
> your computer to other people.
> This isn't generally true with web applications. People often end up
> running web applications that they don't trust in the least. They just
> clicked a link in an email or on a search result page. They still
> expect none of the above things to happen, but not because the pages
> that they end up on won't attempt to do it, but because the browser
> will prevent any of the above from happening.
You're absolutely right, I was merely responding to the claim that every
web app would try to get its workers to have a high priority.
Yes, this is indeed a problem, because that trust is the foundation of the
web platform. We should never allow a developer to abuse the system
resources, intentionally nor unintentionally. Regardless, AFAICT Web Audio
API already breaks that promise as the native nodes can easily eat all the
CPU in a real time thread. However, I made a suggestion on how to mend this
and I think it could be applied to the real time audio workers as well. 
More information about the whatwg