- From: Glenn Maynard <glenn@zewt.org>
- Date: Fri, 10 Aug 2012 15:07:57 -0500
- To: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
- Cc: whatwg@whatwg.org
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). Once people start doing that, everyone has to do it. Limiting this to audio threads probably won't help--people will spin up fake audio threads in order to get higher priority for other work. Limiting the amount of work that can actually be done would probably help this. For example, although you may be giving the thread a timeslice every 10ms, the thread may only have 3ms to do its work and return before being preempted. Audio output threads need to run regularly, but most don't actually do a whole lot of work. Also, note that actual realtime threads in many OSs (including, last I knew, both Windows and Linux) have the capacity to take all CPU and hang the system. I suspect implementations would play it safe and go no higher than "high priority", though you could probably do this safely with careful CPU quotas. (These are all implementation details, of course.) Realtime processing is tricky natively; trying to do this in JS on the web is probably a hard problem. -- Glenn Maynard
Received on Friday, 10 August 2012 20:08:28 UTC