Re: [whatwg] Real-time thread support for workers

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.


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

That's even less helpful, making the audio run in the thread will
effectively counteract any benefits you might get from setting the priority
higher.


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

That depends on use cases, in modern games for example convolution is often
used to simulate space and it's often very CPU-intensive.


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

That is correct, assuming a single-core system, otherwise you'll need more
than one realtime thread. This is something that needs to be thought out
thoroughly. If the UA has the control over the priority of the worker (as
opposed to being a flag set by the developer), the UA can however monitor
the CPU usage of the worker and lower the priority if needed (if the thread
is using 100% CPU the audio is glitching anyway).


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

Not necessarily. Real time processing is hard natively because it imposes a
different set of best practices such as avoiding blocking as much as
possible. The web is by nature designed to be asynchronous and that's also
the model adopted by web developers. If anything, the web is at least by
API design a better place for real time processing.

Cheers,
Jussi

Received on Saturday, 11 August 2012 22:22:45 UTC