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

Re: [whatwg] Proposal: navigator.cores

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 5 May 2014 19:41:07 -0700
Message-ID: <CAGN7qDBwmohdvvtR=mugmvHGeCGLaUW5p+JJ=UMoJ05okY4Vnw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: whatwg <whatwg@lists.whatwg.org>
On Mon, May 5, 2014 at 7:35 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> 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.

This is why this API should return the number of actual parallel tasks that
are allowed by the browser.
There would be no point if this API would return a number that is larger
than that.
Received on Tuesday, 6 May 2014 02:41:33 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:20 UTC