[whatwg] Real-time thread support for workers

[Jonas Sicking]

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.

/ Jonas