22

我理解为什么浏览器供应商不想帮助我阻止他们的 UI 线程。但是,我不明白为什么会有:

  1. Web Worker 中的 no sleep(2)
  2. 没有同步的 WebSockets API

有一个同步的 FileSystem API。还有一个同步 IndexedDB API。在我看来,这似乎是一个矛盾。

4

5 回答 5

15

WebWorkers没有可用功能的原因sleep()很简单:您不需要它。 sleep是一个同步函数,(它在返回之前一直阻塞)在 WebWorkers 的异步上下文中没有意义。

如果您向 WebWorker 发送消息,它不会阻塞等待响应;响应作为消息发送到您的消息处理函数。如果您想在发送响应之前等待一段时间,您不会使用sleep,您会在调用函数时使用setTimeout并触发消息。

同样,如果您使用 WebWorkers 进行 WebSocket 数据传输,您将从主线程接收消息,通过 websocket 异步发送数据包,然后在响应处理程序中将消息发送回主线程。sleep使用同步函数没有合乎逻辑的地方。

至于为什么 WebSockets 没有像文件系统那样的同步模式,主要区别在于文件系统不是通过网络访问的。一般来说,对于基于网络的函数来说,异步 API 更可取,所以我想我不认为它有太大的矛盾。

IDB只支持 3 个浏览器,它们都没有实现同步 API,所以我不认为这是同步 API 的一个光辉例子。事实上,我认为这就是人们会定义 API 而不会费心去实现它的矛盾。

于 2012-10-05T17:41:38.083 回答
9

一点都不明显:TCP协议也是一种网络协议,对吧?它经常在同步模式下使用,因为它使应用程序更易于开发和调试。

在我看来,异步模式在单线程应用程序的上下文中很明显,当您不希望 I/O 阻塞 UI 时。例如,如果您打算使用 Web Worker 来处理后台 I/O,那就不太明显了。将同步 Websocket 与 Web Worker 结合起来确实很方便。

最后,假设文件读取调用将很快完成是不明智的。如果 IO 没有响应,您应该总是有一个超时或接受您的应用程序将挂起的事实。

于 2012-11-25T13:28:29.673 回答
7

对我来说,这是很明显的。

FileSystem API 和 IndexedDB API 以毫秒为单位工作,因此您现在可以放心拥有您的数据,相反,WebSockets API 必须至少慢 100 倍,数据必须在狂野的互联网上传输,因此很明显使其异步。你的回应甚至永远不会回来。

在此处输入图像描述

于 2012-10-06T00:19:15.837 回答
3

索引数据库不会长时间阻塞执行,很可能它会在几毫秒内给出结果,我们不希望在索引数据库中存储数百万条记录。与文件 API 相同,大多数 API 将导致更快的执行。

同步 API 也会导致竞争条件,并且需要多线程同步等,这会增加编程复杂性。相反,基于消息的线程更容易编程,并且我们没有同步问题。

此外,大多数 javascript 引擎都是稳定的,人们熟悉异步编程方式。编写工人更容易也是唯一的方法。改变这一点需要大量重写 javascript 引擎。引入更多的原生 API 将使工作者编程更加复杂。不同的操作系统和不同的架构或设备 wiki 引入了更多的复杂性。

于 2012-10-05T07:33:16.040 回答
1

由于V8 已经实现了 ES2017 await/async,我可以将它与支持 Promise 的库一起使用,并且我不再需要如此糟糕的同步 API。

于 2013-03-28T17:23:41.673 回答