Applications need this API in order to determine how many Web Workers to instantiate in order to parallelize their work.
The problem of how to appropriately size web worker pools has arisen many times in sophisticated web applications and frameworks. Google Maps ran into it (I don't work on that product so can't provide details, but hopefully some member of the team can, if necessary). The three.js framework used to spawn model loaders in web workers, but had to stop doing so when it was found that it was spawning too many and it was difficult to figure out at run time how many would (probably) be beneficial. A prioritization API for Web Workers won't solve this problem, because all of the workers an application requests must actually be spawned for correctness purposes. There's no provision in the web worker specification for allocation of a web worker to fail gracefully, or for a worker to be suspended indefinitely. Even if a worker had its priority designated as "low", it would still need to be started. On 32-bit systems, at least, spawning too many workers will cause the user agent to run out of address space fairly quickly. It would be great to design a new parallelism architecture for the web, but from a practical standpoint, no progress has been made in this area for a number of years, and web developers are hampered today by the absence of this information. I think it should be exposed to the platform. -Ken On Mon, May 5, 2014 at 4:09 PM, João Carlos Martins Eiras <jo...@opera.com> wrote: > Hi. > > I'm just taking a peek at this topic. My first impression is: why > would anyone want such a low level hardware information (CPU cores and > whatnot) on something as high level and abstract as a browser? This > strikes me initially a useful as having the CPU architecture exposed > as well. > > However, I do see the use cases of somehow being more forgiving with > CPU usage. But this would be much better achieved with an API like > defining the priority of workers (high, normal, low) and other async > tasks, and let the user agent do all the resource allocation and > management, because that's what user agents are built to do. In any > case the user agent would make those choices better than the web > developer. > > The only use case I can think of where a web page might want explicit > hardware information is for driver download pages, benchmarks or > collecting statistics. But these cases would be better solved with a > specialized API requiring user consent.