[whatwg] Real-time thread support for workers

[Jussi Kalliokoski]

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
> for
> >>> 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.
> The
> > 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. [1]
Thoughts?

Cheers,
Jussi

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18539