3 ms·

> according to some blog I read, which I couldn't re-find I think this is the blog post by Brendan Eich you are referring to: So my default answer to quest

by jsrn 18y ago

> according to some blog I read, which I couldn't re-find I think this is the blog post by Brendan Eich you are referring to: 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!" There are better ways. Clueful hackers keep rediscovering Erlang. Then there is STM. One retro stylist I know points to an old language-based solution, Hermes. A requirement for JS3 (along with hygienic macros) is to do something along these more implicit lines of concurrency support. In all the fast yet maintainable MT systems I've built or worked on, the key idea (which Will Clinger stated clearly to me over lunch last fall) is to separate the mutable unshared data from the immutable shared data. Do that well, with language and VM support, and threads become what they should be: not an abstraction violator from hell, but a scaling device that can be composed with existing abstractions. So here's a promise about threads, one that I will keep or else buy someone a trip to New Zealand and Australia (or should I say, a trip here for those over there): JS3 will be ready for the multicore desktop workload. http://weblogs.mozillazine.org/roadmap/archives/2007/02/threads_suck.html http://weblogs.mozillazine.org/roadmap/archives/2007/02/thre... in essence, he plans to take advantage of multicore processors not with threads but with better and/or more programmer friendly methods.

ars 18y ago
Yah, that's the one. And we'll see if he delivers, but I know one thing right now: when I sit and wait while one very slow site freezes the whole browser, I get quite annoyed. Does he not realize that the browser is basically the OS these days, and he's keeping it in Windows 3.0 territory? It's time to make a thread for the UI, and a thread for each window, and each tab (child windows AKA popups, shall thread with their parent). JS can't cross those walls anyway, so his probably with concurrency are not as bad as he thinks.
- olavk 18y ago
  I think Eich is advocating against explicit thread support in JavaScript like e.g. Thread.run() in Java. Separate threads per tab is an unrealated issue as long as the tabs cannot communicate. Tabs might however be able to communicate if one tabs opens another through script. In that case it might introduce racing conditions if the tabs runs in different threads. Btw in HTML5 there is a proposal for cross-window communication http://www.w3.org/html/wg/html5/#crossDocumentMessages http://www.w3.org/html/wg/html5/#crossDocumentMessages which is asynchronous. This would allow communication between different threads using message passing.
  - ars 18y ago
    >I think Eich is advocating against explicit thread support in JavaScript Oh! Well I sure read that wrong. I thought he was against threads in the browser. So I guess there is hope. If one tag opens another, it's a child of the first, so they should thread together. Javascript already has threads anyway (setTimer, and events), they are just serially scheduled - on a single core it's identical to regular threads. So you already have to deal with concurrency issues in javascript apps (although it's not as bad as full threading since I think a single function is allowed to run to completion before something else is scheduled).

by jsrn 18y ago

ars 18y ago

Yah, that's the one. And we'll see if he delivers, but I know one thing right now: when I sit and wait while one very slow site freezes the whole browser, I get quite annoyed. Does he not realize that the browser is basically the OS these days, and he's keeping it in Windows 3.0 territory? It's time to make a thread for the UI, and a thread for each window, and each tab (child windows AKA popups, shall thread with their parent). JS can't cross those walls anyway, so his probably with concurrency are not as bad as he thinks.

olavk 18y ago
I think Eich is advocating against explicit thread support in JavaScript like e.g. Thread.run() in Java. Separate threads per tab is an unrealated issue as long as the tabs cannot communicate. Tabs might however be able to communicate if one tabs opens another through script. In that case it might introduce racing conditions if the tabs runs in different threads. Btw in HTML5 there is a proposal for cross-window communication http://www.w3.org/html/wg/html5/#crossDocumentMessages http://www.w3.org/html/wg/html5/#crossDocumentMessages which is asynchronous. This would allow communication between different threads using message passing.
- ars 18y ago
  >I think Eich is advocating against explicit thread support in JavaScript Oh! Well I sure read that wrong. I thought he was against threads in the browser. So I guess there is hope. If one tag opens another, it's a child of the first, so they should thread together. Javascript already has threads anyway (setTimer, and events), they are just serially scheduled - on a single core it's identical to regular threads. So you already have to deal with concurrency issues in javascript apps (although it's not as bad as full threading since I think a single function is allowed to run to completion before something else is scheduled).