为什么WebWorkers无法访问DOM？

Question

我们都知道我们可以启动一些网络工作者，给他们一些平凡的任务，并在某个时刻获得响应，在这个阶段我们通常会解析数据并以某种方式将其呈现给用户。

嗯......任何人都可以提供一个相对深入的解释，说明为什么Web Workers无法访问DOM？考虑到经过深思熟虑的OO设计方法，我只是不明白为什么不应该这样做？

编辑：

我知道这是不可能的，也没有实际答案，但我觉得我需要更深入的解释。如果您觉得这与社区无关，请随时关闭此问题。

Answer 1

浏览器中Javascript的整个世界最初设计有一个巨大的简化 - 单线程（在有webWorkers之前）。这个单一的假设使得编写浏览器变得更简单，因为永远不会有线程争用，并且永远不会是尝试同时修改相同对象或属性的两个活动线程。这使得在浏览器中编写Javascript并在浏览器中实现Javascript更简单。

然后，需要有能力做更长时间的运行＆＃34;背景＆＃34;输入不会阻止主线程的东西。好吧，将它放入现有浏览器中的唯一实用方法是在网上已有数亿页的Javascript，这是为了确保这个＆＃34; new＆＃34; Javascript的线程永远不会搞乱现有的主线程。

所以，它的实现方式是它可以与主线程或主线程可以修改的任何对象（例如整个DOM和几乎所有主机对象）进行通信的唯一方式是通过消息传递，通过它的实现自然地同步并且不受线程争用的影响。

以下是相关答案：Why doesn't JavaScript get its own thread in common browsers?

Answer 2

其他答案是正确的; JS最初设计为单线程作为简化，此时添加多线程必须非常小心。我想详细说明Web Workers中的线程安全性。

当您使用postMessage向工作人员发送消息时，会发生以下三种情况之一，

1. 浏览器将消息序列化为JSON字符串，并在另一端（在工作线程中）进行反序列化。这将创建对象的副本。
2. 浏览器构造消息的结构化克隆，并将其传递给工作线程。这允许使用比1.更复杂的数据类型进行消息传递，但基本上是相同的。
3. 浏览器的转移所有权（或部分内容）。这仅适用于某些数据类型。它是零拷贝，但是一旦主上下文将消息传递给工作者上下文，它就在主上下文中变得不可用。这也是为了避免共享内存。

说到DOM节点，

1. 显然不是一个选项，因为DOM节点包含循环引用，
2. 可以工作，但是处于只读模式，因为工作人员对节点克隆所做的任何更改都不会反映在UI中，并且
遗憾的是，
3. 不是一个选项，因为DOM是一棵树，转移节点的所有权意味着转移整个树的所有权。如果UI线程需要咨询DOM来绘制屏幕并且它没有所有权，则会出现问题。

Answer 3

Web Workers没有DOM访问权限，因为DOM代码不是线程安全的。通过DOM代码，我的意思是浏览器中处理DOM调用的代码。

使线程不安全的代码安全是一个巨大的项目，并没有一个主要的浏览器正在这样做。

Servo项目正在从头开始编写新的浏览器，我认为他们正在编写带有线程安全性的DOM代码。