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