[whatwg] Real-time thread support for workers

[Charles Pritchard]

+1 Jonas.


Though a bit off-topic.

Robert's Audio (and by all obvious means, video/canvas/pixel) workers preserve this trust across all routes.

Unfortunately for developers, there is a lacking trust with vendors in exposing low-level audio-visual-spatial-semantic APIs for sandboxed communication. (also off-topic).

Summary: realtime threads existed and are spec'ed in a simple proposal. They're a specialized instance of web workers. Also, opinions exist about web apps and security.



On Aug 11, 2012, at 8:48 PM, 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.
> 
> / Jonas