<br><div class="gmail_quote">On Wed, Jul 21, 2010 at 1:11 PM, Ryan Heise <span dir="ltr"><<a href="mailto:ryan@ryanheise.com">ryan@ryanheise.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
For all of the reasons above, I would like to see something like threads<br>
in Javascript. Yes, threads give rise to race conditions and deadlocks,<br>
but this seems to be in line with Javascript's apparent philosophy of<br>
doing very little static error checking, and letting things just happen<br>
at runtime (e.g. nonexistent static type system). In other words, this<br>
may be simply a case of: yes, javascript allows runtime errors to<br>
happen. Is not allowing deadlocks important enough that we should make<br>
it impossible for a certain class of algorithms to exploit multi-core<br>
CPUs?<br></blockquote><div><br></div><div>Rather than trying to shoehorn concurrent functionality into Javascript (where many implementations don't support multi-threaded access down at the VM level anyway, so the obstacles to implementation seem fairly large) it seems like a better option is to use a different language entirely.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Before I sign off, there is one more feature which (correct me if I'm<br>
wrong) is lacking from the current specification. There is currently no<br>
way for a program to find out how many cores are present in the host<br>
system. Without this, there is no way to know how many Web Workers to<br>
create for an algorithm that could easily be parallelised to any number<br>
of Web Workers / threads. Even, say, a parallel quicksort should not<br>
just create a new thread for each recursive invocation, as deep as it<br>
goes. For efficiency, this thread creation should stop as soon as enough<br>
threads have been created to match the number of physical cores. After<br>
this point, each core should handle its load by reverting to a<br>
single-threaded quicksort.<br></blockquote><div><br></div><div>There have been a few discussions on this issue - for example:</div><div><br></div><div><a href="http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-November/024058.html">http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-November/024058.html</a></div>
<div><a href="http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/023993.html">http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/023993.html</a></div><div><br></div><div>Not sure if any conclusions were drawn - I think we may have kept this open as an option for v2 of the spec.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
--<br>
<font color="#888888">Ryan Heise<br>
</font></blockquote></div><br>