- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sat, 11 Aug 2012 20:48:59 -0700
- To: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
- Cc: whatwg@whatwg.org, Glenn Maynard <glenn@zewt.org>
On Sat, Aug 11, 2012 at 3:22 PM, Jussi Kalliokoski <jussi.kalliokoski@gmail.com> wrote: > On Fri, Aug 10, 2012 at 11:07 PM, Glenn Maynard <glenn@zewt.org> wrote: > >> On Thu, Aug 9, 2012 at 1:20 AM, Jussi Kalliokoski < >> jussi.kalliokoski@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
Received on Sunday, 12 August 2012 03:50:00 UTC