- From: Mikko Rantalainen <mikko.rantalainen@peda.net>
- Date: Tue, 30 Oct 2012 11:22:28 +0200
- To: whatwg@lists.whatwg.org
Ian Hickson, 2012-10-27 03:14 (Europe/Helsinki): > On Thu, 9 Aug 2012, Jussi Kalliokoski 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. >> >> Thoughts? Is there a big blocker for this that I'm not thinking about or >> has it just not been discussed yet? (I tried to search for it, but >> didn't find anything) > > I think it's impractical to give Web authors this kind of control. User > agents should be able to increase the priority of threads, or notice a > thread is being used for audio and start limiting its per-slice CPU but > increasing the frequency of its slices, but that should be up to the UA, > we can't possibly let Web authors control this, IMHO. Would it be possible to allow web site to request high priority / RT on the expense of getting explicitly limited time slice? For example, API could be something like setMaxLatency(latency) where latency is desired maximum latency in ns. The return value could be maximum time slice in ns. If the worker (repeatedly) went over it maximum time slice, the UA should then revoke the high priority / RT scheduling from said worker and post some kind of event to worker to let it know about the issue. This would prevent any RT worker from hogging the CPU 100% but any well written worker code could be run with very low latency. Notice that the worker can only request desired latency and UA will then tell how much CPU time the worker is allowed to use each slice. The UA should simply return zero if the requested latency is too low to implement. (In this case, the worker would logically always overrun its time sclice and would be re-scheduled back to normal latency.) -- Mikko
Received on Tuesday, 30 October 2012 09:22:54 UTC