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.3.1 : Monday, 13 April 2015 23:09:28 UTC