[webkit-dev] support for navigator.cores or navigator.hardwareConcurrency

Filip Pizlo fpizlo at apple.com
Wed May 7 15:52:30 PDT 2014


Exactly. Ben, Oliver, and others have made arguments against web workers. Rik is not proposing web workers.  We already support them. The point is to give API to let developers opt into behaving nicely if they are already using web workers. 

They can already write code that overloads the system but they currently have *no* way of writing code that even tries to be well-behaved except maybe to avoid workers entirely.

I'm also a little disturbed by arguments against the general usefulness of ncpu. We use it for the parallel JIT and parallel GC because regardless of system load those are *the best* guesses of how many cpus to use.

-Fil

> On May 7, 2014, at 3:24 PM, Rik Cabanier <cabanier at gmail.com> wrote:
> 
> 
> 
> 
>> On Wed, May 7, 2014 at 3:19 PM, Oliver Hunt <oliver at apple.com> wrote:
>> 
>>> On May 7, 2014, at 3:15 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>>> 
>>> 
>>> 
>>> 
>>>> On Wed, May 7, 2014 at 2:47 PM, Oliver Hunt <oliver at apple.com> wrote:
>>>> 
>>>> On May 7, 2014, at 2:41 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>>>> >
>>>> > When would I as a user, not want a page or web application to be as fast as possible? Has a user ever complained about a desktop app that uses too many of his CPU's? I think Oliver's point was that other processes might fight for the same CPU resources but that is not unexpected for users.
>>>> 
>>>> What happen if i go to your website while i'm doing something else in the background?  What if i'm playing a game while waiting for my machine to do something else? What if your page is in the background? Or my battery is running low.
>>> 
>>> Sure. However, a page can already do this today.
>>> This will just give the author a way to make a semi-informed decision. Without this, he might just spin up too many threads and starve the rest of the system.
>>>  
>>>> You need to stop thinking in terms of a user wanting only one thing to happen at a time.
>>> 
>>> I'm not sure if I follow. How would this be any different from a regular desktop application?
>> 
>> 
>> The argument is that this is not behaviour that users want - the fact that desktop applications do this is a bug in the programming model.
>> 
>> APIs like GCD were specifically created to allow a developer to make an application than can automatically scale (or descale) to match the behaviour that is best for the user. That’s the model we want to encourage on the web.
> 
> Filip already covered this much better than I could in the webkit bug: https://bugs.webkit.org/show_bug.cgi?id=132588 
> 
> This proposal is not about inventing a thread/task scheduling mechanism; this is just a way to make an informed guess without having to use a polyfill,
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20140507/5ac3f0a2/attachment.html>


More information about the webkit-dev mailing list