[whatwg] Web Workers

[Drew Wilson]

On Wed, Jul 21, 2010 at 1:11 PM, Ryan Heise <ryan at ryanheise.com> wrote:
>
>
> For all of the reasons above, I would like to see something like threads
> in Javascript. Yes, threads give rise to race conditions and deadlocks,
> but this seems to be in line with Javascript's apparent philosophy of
> doing very little static error checking, and letting things just happen
> at runtime (e.g. nonexistent static type system). In other words, this
> may be simply a case of: yes, javascript allows runtime errors to
> happen. Is not allowing deadlocks important enough that we should make
> it impossible for a certain class of algorithms to exploit multi-core
> CPUs?
>

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.


>
> Before I sign off, there is one more feature which (correct me if I'm
> wrong) is lacking from the current specification. There is currently no
> way for a program to find out how many cores are present in the host
> system. Without this, there is no way to know how many Web Workers to
> create for an algorithm that could easily be parallelised to any number
> of Web Workers / threads. Even, say, a parallel quicksort should not
> just create a new thread for each recursive invocation, as deep as it
> goes. For efficiency, this thread creation should stop as soon as enough
> threads have been created to match the number of physical cores. After
> this point, each core should handle its load by reverting to a
> single-threaded quicksort.
>

There have been a few discussions on this issue - for example:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-November/024058.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/023993.html

Not sure if any conclusions were drawn - I think we may have kept this open
as an option for v2 of the spec.


>
> --
> Ryan Heise
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100721/d4bdb3f9/attachment.htm>