W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2012

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

From: Ian Hickson <ian@hixie.ch>
Date: Sat, 29 Dec 2012 07:18:27 +0000 (UTC)
To: whatwg@whatwg.org
Message-ID: <Pine.LNX.4.64.1212290715560.16292@ps20323.dreamhostps.com>
On Tue, 30 Oct 2012, Mikko Rantalainen wrote:
> 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.)

This is an interesting idea. Is it something any browser vendors would be 
interested in supporting?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 29 December 2012 07:18:56 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:18 UTC