3 ms·

I think the support for web worker threads (OS-level, presumably preemptive multithreading for JS) is potentially the most interesting part of this release, alt

I think the support for web worker threads (OS-level, presumably preemptive multithreading for JS) is potentially the most interesting part of this release, although I don't know how lock-free they are. Moz: https://developer.mozilla.org/En/Using_web_workers https://developer.mozilla.org/En/Using_web_workers WHATWG: http://www.whatwg.org/specs/web-workers/current-work/ http://www.whatwg.org/specs/web-workers/current-work/

axod 17y ago
I really dislike this to be honest. Not having threads ensures the language is nice and simple and pure. Threads in what is pretty much an event driven language, make very little sense. What operations 'block' in js? Threads encourage sloppy inefficient programming. If you start 20 WebWorkers, and it's faster than having 10, you have to ask some serious questions of the interpreter/VM. Like whether it's insane. It should really be up to the interpreter/VM to be able to spread the work over multiple cores, not the programmer of the js.
- mbrubeck 17y ago
  In terms of the programming model, web workers are processes, not threads. They have no shared state, and use asynchronous message passing as the only inter-process communication - very much like Erlang. This makes them very simple, and fits in perfectly with JavaScript's existing asynchronous event-based model. "What operations 'block' in js?" Web workers are important because everything blocks in JavaScript. JS in the browser is single-threaded, which means that if you do anything computationally intensive (reading from a Gears database, sorting a huge array, image manipulation on a Canvas element) then your page can no longer respond to UI events until the processing is finished. Without worker processes, the only way to do long-running computation without blocking the UI was to implement your own cooperative multi-threading by "yielding" with setTimeout(fn, 0). (Note: I'm talking about the model exposed to JS programmers, not the underlying implementation which might be based on native threads, native processes, or green threads.)
  - axod 17y ago
    >> "the only way to do long-running computation without blocking the UI was to implement your own cooperative multi-threading by "yielding" with setTimeout(fn, 0)." Yeah I much prefer that method personally.
  - rmaccloy 17y ago
    Indeed; I kind of did the spec a disservice in calling it multithreading. Moz states it uses OS-level threads, though, and I expect that's what all the common JS/DOM implementations will use.
gjm11 17y ago
Hmmm. Brendan Eich in 2007: http://weblogs.mozillazine.org/roadmap/archives/2007/02/threads_suck.html http://weblogs.mozillazine.org/roadmap/archives/2007/02/thre... '''So my default answer to questions such as the one I got at last May's Ajax Experience, "When will you add threads to JavaScript?" is: "over your dead body!"'''
- mbrubeck 17y ago
  From his comments on the same post: "I think message passing shared nothing beats shared memory preemptively scheduled threads." So Web Workers are an implementation of his preferred solution.

axod 17y ago

I really dislike this to be honest. Not having threads ensures the language is nice and simple and pure. Threads in what is pretty much an event driven language, make very little sense. What operations 'block' in js? Threads encourage sloppy inefficient programming. If you start 20 WebWorkers, and it's faster than having 10, you have to ask some serious questions of the interpreter/VM. Like whether it's insane. It should really be up to the interpreter/VM to be able to spread the work over multiple cores, not the programmer of the js.

mbrubeck 17y ago
In terms of the programming model, web workers are processes, not threads. They have no shared state, and use asynchronous message passing as the only inter-process communication - very much like Erlang. This makes them very simple, and fits in perfectly with JavaScript's existing asynchronous event-based model. "What operations 'block' in js?" Web workers are important because everything blocks in JavaScript. JS in the browser is single-threaded, which means that if you do anything computationally intensive (reading from a Gears database, sorting a huge array, image manipulation on a Canvas element) then your page can no longer respond to UI events until the processing is finished. Without worker processes, the only way to do long-running computation without blocking the UI was to implement your own cooperative multi-threading by "yielding" with setTimeout(fn, 0). (Note: I'm talking about the model exposed to JS programmers, not the underlying implementation which might be based on native threads, native processes, or green threads.)
- axod 17y ago
  >> "the only way to do long-running computation without blocking the UI was to implement your own cooperative multi-threading by "yielding" with setTimeout(fn, 0)." Yeah I much prefer that method personally.
- rmaccloy 17y ago
  Indeed; I kind of did the spec a disservice in calling it multithreading. Moz states it uses OS-level threads, though, and I expect that's what all the common JS/DOM implementations will use.

gjm11 17y ago

Hmmm. Brendan Eich in 2007: http://weblogs.mozillazine.org/roadmap/archives/2007/02/threads_suck.html http://weblogs.mozillazine.org/roadmap/archives/2007/02/thre... '''So my default answer to questions such as the one I got at last May's Ajax Experience, "When will you add threads to JavaScript?" is: "over your dead body!"'''

mbrubeck 17y ago
From his comments on the same post: "I think message passing shared nothing beats shared memory preemptively scheduled threads." So Web Workers are an implementation of his preferred solution.