On 5/5/14, 7:29 PM, Kenneth Russell wrote:
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.

This is not actually true. Nothing in the spec requires a UA to expose the full parallelism of the hardware to workers, so you can just start queueing them when you hit too many; that's not black-box distinguishable from limited hardware resources.

Even if a worker had its
priority designated as "low", it would still need to be started.

Sure, in the sense that the caller has to be able to postMessage to it.

On 32-bit systems, at least, spawning too many workers will cause the
user agent to run out of address space fairly quickly.

You're assuming that each worker, as soon as it can accept messages, has a thread with its own address space dedicated to it.

While this is one possible implementation strategy, it's not required by the spec (and e.g. Gecko does not use this implementation strategy).

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.

Again, note that currently nothing requires a UA to allow an arbitrary number of workers running at once. Gecko will certainly limit the number of in-flight workers available to a particular origin, queueing up new ones until old ones terminate. So navigator.cores on machines with a large number of cores may not actually be a useful measure, since the UA may not allow that many workers to be actively on the CPU at once for a given origin anyway.

Just food for thought,
Boris

Reply via email to