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

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