[whatwg] Real-time thread support for workers

[Glenn Maynard]

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).  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