[whatwg] [WebWorkers] About the delegation example

Drew Wilson a ?crit :
> I think I understand what you're trying to achieve, but it's not clear
> to me that giving the web page a snapshot count of "free cores" is
> actually going to do what you want, given that the number of free
> cores can vary greatly over time.
>
> For example, I launch your page, the browser tells you that there are
> 16 free cores, then I decide to play a flash game or watch video in
> another tab. Suddenly, the number of free cores is no longer correct.
> Alternatively, I launch your page, then I launch *another* copy of
> your page. What happens?
I agree on the fact the a dynamic computation is not a good idea.
However, I still think that a number computed at opening time with only
static values, like number of cores, number of threads/processes allowed
is a good idea. The installation time is not a good idea because after
installation, hardware and OS configuration can be changed (the OS
configs can also be changed while you're running your web browser, but
the relative inaccuracy lifetime is very short).
>
> Exposing information that's not reliable seems worse than not exposing
> it at all, and would encourage applications to grab all available
> resources (after all, that's the purpose of the API!). And the problem
> domains that would benefit from this information (arbitrarily
> parallelizable algorithms like ray tracing) seem to be few in number.
Even if I know that it's true, I don't think it's a good argument to
refuse to add this attibute. The problem domains are few in number, but
for these problems, having this information is very useful. In all the
example we can find on the web the number of workers is always arbitrary
and, in my humble opinion, arbitrary is almost never the best solution
of any problem.

Moreover, the problem domains are few in number today, but we have no
idea of how the web applications will be designed tomorrow.

David
>
> -atw
>
> On Fri, Nov 6, 2009 at 2:41 PM, David Bruant
> <bruant at enseirb-matmeca.fr <mailto:bruant at enseirb-matmeca.fr>> wrote:
>
>     ben turner a ?crit :
>     > I think it's important to note that there is no guarantee that each
>     > worker is tied to an actual OS-level thread. Firefox, for instance,
>     > will schedule workers on a limited number of OS threads to prevent
>     > resource swamping. Other implementations (Chromium only?) create new
>     > processes to run worker code. The only guarantee is that code
>     executed
>     > in a worker will not block the main thread.
>     >
>     I didn't know the differences between the current web workers
>     implementations and that's interesting.
>     The problem with developing JS code using Web workers in a delegation
>     use case is that you cannot predict what is the hardware, the OS
>     and the
>     browser you will run your code on. So, what is the "right", "best"
>     number of workers to use ? 1, 10, 16, 1000 ? It is not a defined
>     number,
>     it depends on hardware, OS and browser (or any user agent, of course).
>
>     My point is to give this information to the developer.
>
>     If FF decides that all the workers will run on 3 OS threads even if
>     you're on a 16-core, my number is 3. If you're in Chrome and your OS
>     allows you to create only one more process, this number is 1. If
>     you're
>     in Chrome and your OS allow you to create "as many processes as you
>     want" on a quad-core, this number is 4. But for each case, the web
>     browser can ask this information to the OS (once when you install it ?
>     each time you open your browser ? dynamically ?).
>
>     This information is available (and shouldn't be that hard to
>     retrieve !)
>     and can be given to the web developer.
>
>     David
>
>     > -Ben
>     >
>
>

Received on Friday, 6 November 2009 15:43:57 UTC