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.

Reply via email to