Is it a deliberate design decision or a problem with our current day browsers which will be rectified in the coming versions?
这是一个深思熟虑的设计决定还是我们当前浏览器的一个问题,将在未来的版本中得到纠正?
15 个解决方案
#1
144
JavaScript does not support multi-threading because the JavaScript interpreter in the browser is a single thread (AFAIK). Even Google Chrome will not let a single web page’s JavaScript run concurrently because this would cause massive concurrency issues in existing web pages. All Chrome does is separate multiple components (different tabs, plug-ins, etcetera) into separate processes, but I can’t imagine a single page having more than one JavaScript thread.
JavaScript不支持多线程,因为浏览器中的JavaScript解释器是单个线程(AFAIK)。甚至谷歌Chrome也不会让一个web页面的JavaScript并发运行,因为这会导致现有web页面出现大量并发性问题。所有的Chrome都是将多个组件(不同的选项卡、插件等等)分离到单独的进程中,但是我无法想象一个单独的页面会有多个JavaScript线程。
You can however use, as was suggested, setTimeout
to allow some sort of scheduling and “fake” concurrency. This causes the browser to regain control of the rendering thread, and start the JavaScript code supplied to setTimeout
after the given number of milliseconds. This is very useful if you want to allow the viewport (what you see) to refresh while performing operations on it. Just looping through e.g. coordinates and updating an element accordingly will just let you see the start and end positions, and nothing in between.
但是,正如建议的那样,您可以使用setTimeout来允许某种排序和“伪”并发。这将导致浏览器重新获得呈现线程的控制权,并在给定的毫秒数之后启动提供给setTimeout的JavaScript代码。如果您想让viewport(您看到的)在执行操作时刷新,这将非常有用。只是循环通过例如坐标和更新一个元素会让你看到开始和结束的位置,中间没有任何东西。
We use an abstraction library in JavaScript that allows us to create processes and threads which are all managed by the same JavaScript interpreter. This allows us to run actions in the following manner:
我们使用JavaScript中的抽象库来创建进程和线程,这些进程和线程都由同一个JavaScript解释器管理。这允许我们以下列方式运行操作:
- Process A, Thread 1
- 进程,线程1
- Process A, Thread 2
- 进程,线程2
- Process B, Thread 1
- 进程B,线程1
- Process A, Thread 3
- 进程,线程3
- Process A, Thread 4
- 进程,线程4
- Process B, Thread 2
- 进程B,线程2
- Pause Process A
- 暂停处理
- Process B, Thread 3
- 进程B,线程3
- Process B, Thread 4
- 进程B,线程4
- Process B, Thread 5
- 进程B,线程5
- Start Process A
- 开始处理
- Process A, Thread 5
- 进程,线程5
This allows some form of scheduling and fakes parallelism, starting and stopping of threads, etcetera, but it will not be true multi-threading. I don’t think it will ever be implemented in the language itself, since true multi-threading is only useful if the browser can run a single page multi-threaded (or even more than one core), and the difficulties there are way larger than the extra possibilities.
这允许某种形式的调度和伪并行性、线程的启动和停止等等,但它不会是真正的多线程。我不认为它会在语言本身中实现,因为真正的多线程只在浏览器能够运行一个单页多线程(甚至不止一个核心)的情况下才有用,而且这些困难比额外的可能性要大得多。
For the future of JavaScript, check this out: http://developer.mozilla.org/presentations/xtech2006/javascript/
对于JavaScript的未来,请查看以下内容:http://developer.mozilla.org/presentations/xtech2006/javascript/。
#2
21
Traditionally, JS was intended for short, quick-running pieces of code. If you had major calculations going on, you did it on a server - the idea of a JS+HTML app that ran in your browser for long periods of time doing non-trivial things was absurd.
传统上,JS的目的是简短、快速运行的代码片段。如果你进行了重大的计算,你就在服务器上完成了——一个JS+HTML应用程序在你的浏览器中运行很长一段时间,做一些非平凡的事情是荒谬的。
Of course, now we have that. But, it'll take a bit for browsers to catch up - most of them have been designed around a single-threaded model, and changing that is not easy. Google Gears side-steps a lot of potential problems by requiring that background execution is isolated - no changing the DOM (since that's not thread-safe), no accessing objects created by the main thread (ditto). While restrictive, this will likely be the most practical design for the near future, both because it simplifies the design of the browser, and because it reduces the risk involved in allowing inexperienced JS coders mess around with threads...
当然,现在我们有了。但是,要想赶上浏览器需要一点时间——大多数浏览器都是围绕单线程模型设计的,而且改变起来并不容易。谷歌Gears通过要求后台执行是隔离的——不改变DOM(因为这不是线程安全的),没有访问主线程创建的对象(ditto),从而避免了许多潜在的问题。虽然限制,但这可能是近期最实用的设计,因为它简化了浏览器的设计,而且因为它降低了让没有经验的JS程序员使用线程的风险。
@marcio:
Why is that a reason not to implement multi-threading in Javascript? Programmers can do whatever they want with the tools they have.
为什么不使用Javascript实现多线程呢?程序员可以用他们拥有的工具做任何他们想做的事情。
So then, let's not give them tools that are so easy to misuse that every other website i open ends up crashing my browser. A naive implementation of this would bring you straight into the territory that caused MS so many headaches during IE7 development: add-on authors played fast and loose with the threading model, resulting in hidden bugs that became evident when object lifecycles changed on the primary thread. BAD. If you're writing multi-threaded ActiveX add-ons for IE, i guess it comes with the territory; doesn't mean it needs to go any further than that.
所以,我们不要给他们提供那些容易被滥用的工具,我打开的其他网站都会破坏我的浏览器。这种简单的实现会让您直接进入导致IE7开发过程中许多头痛的领域:附加的作者在线程模型中快速而松散地使用,导致隐藏的bug在对象生命周期在主线程上发生变化时变得明显。坏的。如果你正在为IE编写多线程的ActiveX附加组件,我想它会与这个领域一起出现;这并不意味着它需要更进一步。
#3
19
JavaScript multi-threading (with some limitations) is here. Google implemented workers for Gears, and workers are being included with HTML5. Most browsers have already added support for this feature.
JavaScript多线程(有一些限制)在这里。谷歌为Gears实现了工人,而工人们也被纳入了HTML5。大多数浏览器已经添加了对该特性的支持。
Thread-safety of data is guaranteed because all data communicated to/from the worker is serialized/copied.
确保数据的线程安全,因为所有与worker通信的数据都是序列化/复制的。
For more info, read:
更多信息,请阅读:
http://www.whatwg.org/specs/web-workers/current-work/
http://www.whatwg.org/specs/web-workers/current-work/
http://ejohn.org/blog/web-workers/
http://ejohn.org/blog/web-workers/
#4
11
I don't know the rationale for this decision, but I know that you can simulate some of the benefits of multi-threaded programming using setTimeout. You can give the illusion of multiple processes doing things at the same time, though in reality, everything happens in one thread.
我不知道这个决定的基本原理,但是我知道您可以使用setTimeout模拟多线程编程的一些好处。你可以让多个进程同时做事情的幻觉,尽管在现实中,所有事情都发生在一个线程中。
Just have your function do a little bit of work, and then call something like:
让你的函数做一些工作,然后调用一些类似的东西:
setTimeout(function () {
... do the rest of the work...
}, 0);
And any other things that need doing (like UI updates, animated images, etc) will happen when they get a chance.
还有其他需要做的事情(比如UI更新、动画图像等),当他们有机会的时候就会发生。
#5
9
Multithread.js wraps Web Workers and allows for easy multithreading in JS. Works on all new browsers, including iOS Safari. :)
多流。js封装了Web Workers,并允许使用js轻松多线程。适用于所有新浏览器,包括iOS Safari。:)
#6
6
Do you mean why doesn't the language support multithreading or why don't JavaScript engines in browsers support multithreading?
您的意思是,为什么语言支持多线程,或者为什么浏览器中的JavaScript引擎不支持多线程?
The answer to the first question is that JavaScript in the browser is meant to be run in a sandbox and in a machine/OS-independent way, to add multithreading support would complicate the language and tie the language too closely to the OS.
第一个问题的答案是,浏览器中的JavaScript应该是在沙箱中运行,在机器/OS独立的方式下,添加多线程支持会使语言复杂化,并将语言与操作系统紧密地联系在一起。
#7
5
Just as matt b said, the question is not very clear. Assuming that you are asking about multithreading support in the language: because it isn't needed for 99.999% of the applications running in the browser currently. If you really need it, there are workarounds (like using window.setTimeout).
正如matt b所说,这个问题不是很清楚。假设您正在询问语言中的多线程支持:因为目前在浏览器中运行的应用程序不需要99.999%的应用程序。如果您确实需要它,那么就有一些变通方法(比如使用window.setTimeout)。
In general multithreading is very, very, very, very, very, very hard (did I say that it is hard?) to get right, unless you put in extra restrictions (like using only immutable data).
一般来说,多线程是非常非常非常非常困难的(我说过它很难吗?),除非你添加了额外的限制(比如只使用不可变数据)。
#8
3
Intel has been doing some open-source research on multithreading in Javascript, it was showcased recently on GDC 2012. Here is the link for the video. The research group used OpenCL which primarily focuses on Intel Chip sets and Windows OS. The project is code-named RiverTrail and the code is available on GitHub
Intel最近在Javascript上做了一些关于多线程的开源研究,最近在GDC 2012上展示了它。这是视频的链接。研究小组使用OpenCL,主要关注英特尔芯片组和Windows操作系统。该项目代号为RiverTrail,代码在GitHub上可用。
Some more useful links:
一些更有用的链接:
Building a Computing Highway for Web Applications
为Web应用程序构建计算高速公路。
#9
2
Currently some browsers do support multithreading. So, if you need that you could use specific libraries. For example, view the next materials:
目前一些浏览器确实支持多线程。因此,如果您需要,您可以使用特定的库。例如,查看下一个材料:
-
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers (support background threads);
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers(支持后台线程);
-
https://keithwhor.github.io/multithread.js/ (the library).
https://keithwhor.github.io/multithread。js /(图书馆)。
#10
0
As far as I have heared Google Chrome will have multithreaded javascript, so it is a "current implementations" problem.
就我所知,谷歌Chrome将有多线程的javascript,所以它是一个“当前实现”的问题。
#11
0
According to this article it is already possible to implement JavaScript threading.
根据本文,已经可以实现JavaScript线程。
#12
0
It's the implementations that doesn't support multi-threading. Currently Google Gears is providing a way to use some form of concurrency by executing external processes but that's about it.
它是不支持多线程的实现。目前谷歌Gears提供了一种通过执行外部进程来使用某种形式的并发性的方法,但这是关于它的。
The new browser Google is supposed to release today (Google Chrome) executes some code in parallel by separating it in process.
新的浏览器谷歌应该在今天发布(谷歌Chrome),通过将它与进程分开来并行执行一些代码。
The core language, of course can have the same support as, say Java, but support for something like Erlang's concurrency is nowhere near the horizon.
当然,核心语言可以得到和Java一样的支持,但是对于类似Erlang的并发性的支持还远远不够。
#13
0
Without proper language support for thread syncronization, it doesn't even make sense for new implementations to try. Existing complex JS apps (e.g. anything using ExtJS) would most likely crash unexpectedly, but without a synchronized
keyword or something similar, it would also be very hard or even impossible to write new programs that behave correctly.
如果没有对线程同步化的适当语言支持,那么新的实现就没有意义了。现有的复杂JS应用程序(例如任何使用ExtJS的应用程序)很可能会意外地崩溃,但是如果没有同步的关键字或类似的东西,那么编写正确的新程序也会非常困难甚至是不可能的。
#14
0
However you can use eval function to bring concurrency TO SOME EXTENT
但是,您可以使用eval函数在一定程度上实现并发。
/* content of the threads to be run */
var threads = [
[
"document.write('Foo <br/>');",
"document.write('Foo <br/>');",
"document.write('Foo <br/>');",
"document.write('Foo <br/>');",
"document.write('Foo <br/>');",
"document.write('Foo <br/>');",
"document.write('Foo <br/>');",
"document.write('Foo <br/>');",
"document.write('Foo <br/>');",
"document.write('Foo <br/>');"
],
[
"document.write('Bar <br/>');",
"document.write('Bar <br/>');",
"document.write('Bar <br/>');",
"document.write('Bar <br/>');",
"document.write('Bar <br/>');",
"document.write('Bar <br/>');",
"document.write('Bar <br/>');",
"document.write('Bar <br/>');",
"document.write('Bar <br/>');"
]
];
window.onload = function() {
var lines = 0, quantum = 3, max = 0;
/* get the longer thread length */
for(var i=0; i<threads.length; i++) {
if(max < threads[i].length) {
max = threads[i].length;
}
}
/* execute them */
while(lines < max) {
for(var i=0; i<threads.length; i++) {
for(var j = lines; j < threads[i].length && j < (lines + quantum); j++) {
eval(threads[i][j]);
}
}
lines += quantum;
}
}
#15
-2
Multi-threading with javascript is clearly possible using webworkers bring by HTML5.
使用HTML5可以很清楚地使用webworker带来的多线程。
Main difference between webworkers and a standard multi-threading environment is memory resources are not shared with the main thread, a reference to an object is not visible from one thread to another. Threads communicate by exchanging messages, it is therefore possible to implement a synchronzization and concurrent method call algorithm following an event-driven design pattern.
webworkers和标准多线程环境之间的主要区别是内存资源不与主线程共享,对对象的引用不能从一个线程到另一个线程。线程通过交换消息进行通信,因此可以在事件驱动的设计模式下实现同步和并发方法调用算法。
Many frameworks exists allowing to structure programmation between threads, among them OODK-JS, an OOP js framework supporting concurrent programming https://github.com/GOMServices/oodk-js-oop-for-js
许多框架都允许在线程之间进行结构编程,其中包括OODK-JS,一个支持并发编程的OOP js框架,https://github.com/gomservices/oodk -js-oop- js。
#1
144
JavaScript does not support multi-threading because the JavaScript interpreter in the browser is a single thread (AFAIK). Even Google Chrome will not let a single web page’s JavaScript run concurrently because this would cause massive concurrency issues in existing web pages. All Chrome does is separate multiple components (different tabs, plug-ins, etcetera) into separate processes, but I can’t imagine a single page having more than one JavaScript thread.
JavaScript不支持多线程,因为浏览器中的JavaScript解释器是单个线程(AFAIK)。甚至谷歌Chrome也不会让一个web页面的JavaScript并发运行,因为这会导致现有web页面出现大量并发性问题。所有的Chrome都是将多个组件(不同的选项卡、插件等等)分离到单独的进程中,但是我无法想象一个单独的页面会有多个JavaScript线程。
You can however use, as was suggested, setTimeout
to allow some sort of scheduling and “fake” concurrency. This causes the browser to regain control of the rendering thread, and start the JavaScript code supplied to setTimeout
after the given number of milliseconds. This is very useful if you want to allow the viewport (what you see) to refresh while performing operations on it. Just looping through e.g. coordinates and updating an element accordingly will just let you see the start and end positions, and nothing in between.
但是,正如建议的那样,您可以使用setTimeout来允许某种排序和“伪”并发。这将导致浏览器重新获得呈现线程的控制权,并在给定的毫秒数之后启动提供给setTimeout的JavaScript代码。如果您想让viewport(您看到的)在执行操作时刷新,这将非常有用。只是循环通过例如坐标和更新一个元素会让你看到开始和结束的位置,中间没有任何东西。
We use an abstraction library in JavaScript that allows us to create processes and threads which are all managed by the same JavaScript interpreter. This allows us to run actions in the following manner:
我们使用JavaScript中的抽象库来创建进程和线程,这些进程和线程都由同一个JavaScript解释器管理。这允许我们以下列方式运行操作:
- Process A, Thread 1
- 进程,线程1
- Process A, Thread 2
- 进程,线程2
- Process B, Thread 1
- 进程B,线程1
- Process A, Thread 3
- 进程,线程3
- Process A, Thread 4
- 进程,线程4
- Process B, Thread 2
- 进程B,线程2
- Pause Process A
- 暂停处理
- Process B, Thread 3
- 进程B,线程3
- Process B, Thread 4
- 进程B,线程4
- Process B, Thread 5
- 进程B,线程5
- Start Process A
- 开始处理
- Process A, Thread 5
- 进程,线程5
This allows some form of scheduling and fakes parallelism, starting and stopping of threads, etcetera, but it will not be true multi-threading. I don’t think it will ever be implemented in the language itself, since true multi-threading is only useful if the browser can run a single page multi-threaded (or even more than one core), and the difficulties there are way larger than the extra possibilities.
这允许某种形式的调度和伪并行性、线程的启动和停止等等,但它不会是真正的多线程。我不认为它会在语言本身中实现,因为真正的多线程只在浏览器能够运行一个单页多线程(甚至不止一个核心)的情况下才有用,而且这些困难比额外的可能性要大得多。
For the future of JavaScript, check this out: http://developer.mozilla.org/presentations/xtech2006/javascript/
对于JavaScript的未来,请查看以下内容:http://developer.mozilla.org/presentations/xtech2006/javascript/。
#2
21
Traditionally, JS was intended for short, quick-running pieces of code. If you had major calculations going on, you did it on a server - the idea of a JS+HTML app that ran in your browser for long periods of time doing non-trivial things was absurd.
传统上,JS的目的是简短、快速运行的代码片段。如果你进行了重大的计算,你就在服务器上完成了——一个JS+HTML应用程序在你的浏览器中运行很长一段时间,做一些非平凡的事情是荒谬的。
Of course, now we have that. But, it'll take a bit for browsers to catch up - most of them have been designed around a single-threaded model, and changing that is not easy. Google Gears side-steps a lot of potential problems by requiring that background execution is isolated - no changing the DOM (since that's not thread-safe), no accessing objects created by the main thread (ditto). While restrictive, this will likely be the most practical design for the near future, both because it simplifies the design of the browser, and because it reduces the risk involved in allowing inexperienced JS coders mess around with threads...
当然,现在我们有了。但是,要想赶上浏览器需要一点时间——大多数浏览器都是围绕单线程模型设计的,而且改变起来并不容易。谷歌Gears通过要求后台执行是隔离的——不改变DOM(因为这不是线程安全的),没有访问主线程创建的对象(ditto),从而避免了许多潜在的问题。虽然限制,但这可能是近期最实用的设计,因为它简化了浏览器的设计,而且因为它降低了让没有经验的JS程序员使用线程的风险。
@marcio:
Why is that a reason not to implement multi-threading in Javascript? Programmers can do whatever they want with the tools they have.
为什么不使用Javascript实现多线程呢?程序员可以用他们拥有的工具做任何他们想做的事情。
So then, let's not give them tools that are so easy to misuse that every other website i open ends up crashing my browser. A naive implementation of this would bring you straight into the territory that caused MS so many headaches during IE7 development: add-on authors played fast and loose with the threading model, resulting in hidden bugs that became evident when object lifecycles changed on the primary thread. BAD. If you're writing multi-threaded ActiveX add-ons for IE, i guess it comes with the territory; doesn't mean it needs to go any further than that.
所以,我们不要给他们提供那些容易被滥用的工具,我打开的其他网站都会破坏我的浏览器。这种简单的实现会让您直接进入导致IE7开发过程中许多头痛的领域:附加的作者在线程模型中快速而松散地使用,导致隐藏的bug在对象生命周期在主线程上发生变化时变得明显。坏的。如果你正在为IE编写多线程的ActiveX附加组件,我想它会与这个领域一起出现;这并不意味着它需要更进一步。
#3
19
JavaScript multi-threading (with some limitations) is here. Google implemented workers for Gears, and workers are being included with HTML5. Most browsers have already added support for this feature.
JavaScript多线程(有一些限制)在这里。谷歌为Gears实现了工人,而工人们也被纳入了HTML5。大多数浏览器已经添加了对该特性的支持。
Thread-safety of data is guaranteed because all data communicated to/from the worker is serialized/copied.
确保数据的线程安全,因为所有与worker通信的数据都是序列化/复制的。
For more info, read:
更多信息,请阅读:
http://www.whatwg.org/specs/web-workers/current-work/
http://www.whatwg.org/specs/web-workers/current-work/
http://ejohn.org/blog/web-workers/
http://ejohn.org/blog/web-workers/
#4
11
I don't know the rationale for this decision, but I know that you can simulate some of the benefits of multi-threaded programming using setTimeout. You can give the illusion of multiple processes doing things at the same time, though in reality, everything happens in one thread.
我不知道这个决定的基本原理,但是我知道您可以使用setTimeout模拟多线程编程的一些好处。你可以让多个进程同时做事情的幻觉,尽管在现实中,所有事情都发生在一个线程中。
Just have your function do a little bit of work, and then call something like:
让你的函数做一些工作,然后调用一些类似的东西:
setTimeout(function () {
... do the rest of the work...
}, 0);
And any other things that need doing (like UI updates, animated images, etc) will happen when they get a chance.
还有其他需要做的事情(比如UI更新、动画图像等),当他们有机会的时候就会发生。
#5
9
Multithread.js wraps Web Workers and allows for easy multithreading in JS. Works on all new browsers, including iOS Safari. :)
多流。js封装了Web Workers,并允许使用js轻松多线程。适用于所有新浏览器,包括iOS Safari。:)
#6
6
Do you mean why doesn't the language support multithreading or why don't JavaScript engines in browsers support multithreading?
您的意思是,为什么语言支持多线程,或者为什么浏览器中的JavaScript引擎不支持多线程?
The answer to the first question is that JavaScript in the browser is meant to be run in a sandbox and in a machine/OS-independent way, to add multithreading support would complicate the language and tie the language too closely to the OS.
第一个问题的答案是,浏览器中的JavaScript应该是在沙箱中运行,在机器/OS独立的方式下,添加多线程支持会使语言复杂化,并将语言与操作系统紧密地联系在一起。
#7
5
Just as matt b said, the question is not very clear. Assuming that you are asking about multithreading support in the language: because it isn't needed for 99.999% of the applications running in the browser currently. If you really need it, there are workarounds (like using window.setTimeout).
正如matt b所说,这个问题不是很清楚。假设您正在询问语言中的多线程支持:因为目前在浏览器中运行的应用程序不需要99.999%的应用程序。如果您确实需要它,那么就有一些变通方法(比如使用window.setTimeout)。
In general multithreading is very, very, very, very, very, very hard (did I say that it is hard?) to get right, unless you put in extra restrictions (like using only immutable data).
一般来说,多线程是非常非常非常非常困难的(我说过它很难吗?),除非你添加了额外的限制(比如只使用不可变数据)。
#8
3
Intel has been doing some open-source research on multithreading in Javascript, it was showcased recently on GDC 2012. Here is the link for the video. The research group used OpenCL which primarily focuses on Intel Chip sets and Windows OS. The project is code-named RiverTrail and the code is available on GitHub
Intel最近在Javascript上做了一些关于多线程的开源研究,最近在GDC 2012上展示了它。这是视频的链接。研究小组使用OpenCL,主要关注英特尔芯片组和Windows操作系统。该项目代号为RiverTrail,代码在GitHub上可用。
Some more useful links:
一些更有用的链接:
Building a Computing Highway for Web Applications
为Web应用程序构建计算高速公路。
#9
2
Currently some browsers do support multithreading. So, if you need that you could use specific libraries. For example, view the next materials:
目前一些浏览器确实支持多线程。因此,如果您需要,您可以使用特定的库。例如,查看下一个材料:
-
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers (support background threads);
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers(支持后台线程);
-
https://keithwhor.github.io/multithread.js/ (the library).
https://keithwhor.github.io/multithread。js /(图书馆)。
#10
0
As far as I have heared Google Chrome will have multithreaded javascript, so it is a "current implementations" problem.
就我所知,谷歌Chrome将有多线程的javascript,所以它是一个“当前实现”的问题。
#11
0
According to this article it is already possible to implement JavaScript threading.
根据本文,已经可以实现JavaScript线程。
#12
0
It's the implementations that doesn't support multi-threading. Currently Google Gears is providing a way to use some form of concurrency by executing external processes but that's about it.
它是不支持多线程的实现。目前谷歌Gears提供了一种通过执行外部进程来使用某种形式的并发性的方法,但这是关于它的。
The new browser Google is supposed to release today (Google Chrome) executes some code in parallel by separating it in process.
新的浏览器谷歌应该在今天发布(谷歌Chrome),通过将它与进程分开来并行执行一些代码。
The core language, of course can have the same support as, say Java, but support for something like Erlang's concurrency is nowhere near the horizon.
当然,核心语言可以得到和Java一样的支持,但是对于类似Erlang的并发性的支持还远远不够。
#13
0
Without proper language support for thread syncronization, it doesn't even make sense for new implementations to try. Existing complex JS apps (e.g. anything using ExtJS) would most likely crash unexpectedly, but without a synchronized
keyword or something similar, it would also be very hard or even impossible to write new programs that behave correctly.
如果没有对线程同步化的适当语言支持,那么新的实现就没有意义了。现有的复杂JS应用程序(例如任何使用ExtJS的应用程序)很可能会意外地崩溃,但是如果没有同步的关键字或类似的东西,那么编写正确的新程序也会非常困难甚至是不可能的。
#14
0
However you can use eval function to bring concurrency TO SOME EXTENT
但是,您可以使用eval函数在一定程度上实现并发。
/* content of the threads to be run */
var threads = [
[
"document.write('Foo <br/>');",
"document.write('Foo <br/>');",
"document.write('Foo <br/>');",
"document.write('Foo <br/>');",
"document.write('Foo <br/>');",
"document.write('Foo <br/>');",
"document.write('Foo <br/>');",
"document.write('Foo <br/>');",
"document.write('Foo <br/>');",
"document.write('Foo <br/>');"
],
[
"document.write('Bar <br/>');",
"document.write('Bar <br/>');",
"document.write('Bar <br/>');",
"document.write('Bar <br/>');",
"document.write('Bar <br/>');",
"document.write('Bar <br/>');",
"document.write('Bar <br/>');",
"document.write('Bar <br/>');",
"document.write('Bar <br/>');"
]
];
window.onload = function() {
var lines = 0, quantum = 3, max = 0;
/* get the longer thread length */
for(var i=0; i<threads.length; i++) {
if(max < threads[i].length) {
max = threads[i].length;
}
}
/* execute them */
while(lines < max) {
for(var i=0; i<threads.length; i++) {
for(var j = lines; j < threads[i].length && j < (lines + quantum); j++) {
eval(threads[i][j]);
}
}
lines += quantum;
}
}
#15
-2
Multi-threading with javascript is clearly possible using webworkers bring by HTML5.
使用HTML5可以很清楚地使用webworker带来的多线程。
Main difference between webworkers and a standard multi-threading environment is memory resources are not shared with the main thread, a reference to an object is not visible from one thread to another. Threads communicate by exchanging messages, it is therefore possible to implement a synchronzization and concurrent method call algorithm following an event-driven design pattern.
webworkers和标准多线程环境之间的主要区别是内存资源不与主线程共享,对对象的引用不能从一个线程到另一个线程。线程通过交换消息进行通信,因此可以在事件驱动的设计模式下实现同步和并发方法调用算法。
Many frameworks exists allowing to structure programmation between threads, among them OODK-JS, an OOP js framework supporting concurrent programming https://github.com/GOMServices/oodk-js-oop-for-js
许多框架都允许在线程之间进行结构编程,其中包括OODK-JS,一个支持并发编程的OOP js框架,https://github.com/gomservices/oodk -js-oop- js。