[whatwg] Real-time thread support for workers

[David Bruant]

Le 09/08/2012 02:20, Jussi Kalliokoski a écrit :
> Hello there!
>
> 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.
There are 3 sources of potential CPU stress.
* One is external to the web browser (other programs) and obviously web 
content shouldn't be allowed to have any influence on that.
* One is in the web browser, but not the audio content you wish wasn't 
glitching (other tabs/different origin iframes). Once again, I don't 
think it's a good idea to have content influencing other content CPU use 
(otherwise, all content will decide to go on high priority for anything, 
which defeats the purpose).
* The last source is your own content competing with itself for CPU.
One question I have is whether different parts of your own content (like 
different workers) should declare which priority should be given or 
whether the application should be written in a way that is resistant to 
high CPU stress (e.g. doing few work besides audio work).

Since the only relevant case for priorities is the third one, I'd like 
to question the relevance of the use case.
Is implementing per-browsing-content web worker priority worth the 
result? Will we be able to really notice an improvement in the audio 
quality that often?

I would be more in favor of browsers sharing with content how busy the 
CPU is (in a way or another) so that the content shuts down things 
itself and decides programmatically what is worth running and what isn't.

David