当存在同步FileSystem支持时,为什么Web Workers中没有同步WebSocket支持?

Jan*_*sen 22 javascript policy w3c asynchronous web-standards

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

  1. 在Web Workers中没有睡觉(2)
  2. 没有同步WebSockets API

有一个同步的FileSystem API.还有一个同步的IndexedDB API.对我来说,这似乎是一个矛盾.

sam*_*aml 15

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

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

类似地,如果您使用WebWorkers进行WebSocket数据传输,您将从主线程接收消息,通过websocket异步发送数据包,然后在响应处理程序中将消息发送回主线程.没有合理的地方可以使用同步sleep功能.

至于为什么没有像文件系统那样的WebSockets同步模式,主要的区别是文件系统不能通过网络访问.通常,异步API更适合基于网络的功能,所以我想我不认为这是一个矛盾.

IDB 仅由3个浏览器支持,其中没有一个已实现同步API,因此我不认为它是同步API的光辉示例.事实上,我认为这是人们定义API而不愿意实现它的矛盾.


小智 9

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

在我看来,当您不希望I/O阻止UI时,异步模式在单线程应用程序的上下文中是显而易见的.如果您打算使用Web worker来处理后台I/O,那么它就不那么容易了.将同步Websocket与Web worker结合使用确实很方便.

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


Ma *_*rez 7

对我来说这很明显.

文件系统API和IndexedDB的API以毫秒为单位的顺序工作,所以你可以信任您的数据,现在,而不是它的WebSockets API必须慢至少100倍,数据必须飞过野生互联网,那么很明显,使其同步.您的回复甚至可以永远回复.

在此输入图像描述


Jan*_*sen 1

由于V8 已经实现了 ES2017 wait/async,我可以将其与启用 Promise 的库一起使用,并且我不再那么需要同步 API。