我正在使用网络工作者来执行一些 CPU 密集型工作，但要求工作者将在工作者仍在处理时响应来自父脚本的消息。
但是，工作人员在被锁定在处理循环中时不会响应消息，而且我还没有找到一种方法来轮询消息队列。因此，似乎唯一的解决方案是每隔一段时间中断处理以允许处理队列中的任何消息。
显而易见的选择是使用计时器（比如使用 setInterval）但是我已经读到两次触发之间的最小延迟很长（http://ajaxian.com/archives/settimeout-delay），这是不幸的，因为它会减慢处理速度很多。
其他人对此有何看法？我将尝试让工作人员onmessage在 each 结束时将其分派给自己onmessage，从而有效地执行每个从自身收到的事件的处理循环的一个步骤，但只是想看看是否有人对此有任何想法。
谢谢，
工人可以产生子工人。你可以让你的主工作者充当你的消息队列，当它收到一个长时间运行的操作请求时，产生一个子工作者来处理该数据。然后子工作人员可以将结果发送回主工作人员以从队列中删除事件并将结果返回给主线程。这样，您的主要工作人员将始终可以自由地收听新消息，并且您可以完全控制队列。
- 缺口
我第一次和工人一起玩时遇到了这个问题。我也讨论过使用 setInterval，但我觉得这将是解决问题的一种相当老套的方法（而且我已经为我的模拟多线程采用了这种方法）。相反，我决定从主线程 (worker.terminate()) 终止工作人员，并在他们参与的任务需要中断时重新创建它们。垃圾收集等似乎在我的测试中得到处理。
如果这些任务中有数据要保存，你可以定期将其发布回主线程进行存储，如果你希望实现一些关于它们是否终止的逻辑，你可以发布以足够的时间间隔定期返回相关数据以允许它。
无论如何，产生 subworkers 会导致同样的问题。您仍然必须根据某些逻辑终止子工作者（或创建新子工作者），而且我不确定它是否得到很好的支持（例如在 chrome 上）。
詹姆士
遇到同样的问题，我搜索了 web workers 的草稿，在处理模型部分找到了一些东西，从 9 到 12 步。据我所知，开始处理任务的工作人员在第一个任务完成之前不会处理另一个任务。因此，如果您不关心停止和恢复任务，nciagra 的答案应该比重新安排任务的每次迭代提供更好的性能。
不过还在调查。