W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2014

Re: [whatwg] Proposal: navigator.cores

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 05 May 2014 22:35:46 -0400
Message-ID: <53684A82.3020308@mit.edu>
To: whatwg@lists.whatwg.org
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,
Received on Tuesday, 6 May 2014 02:36:14 UTC

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