工作池vs libuv在node.js中的线程池

Question

我正在阅读有关worker pool的node.js文档，并且遇到了两个我认为都相同的术语 - where和worker pool。

这是混淆点（来自node.js doc url）：

这些是使用此工作池的节点模块API：

I / O密集型

DNS： libuv's threadpool，dns.lookup()。

文件系统：除dns.lookupService()之外的所有文件系统API 以及明确同步的文件系统API使用libuv的线程池。

到目前为止，我的理解是这样的：

fs.FSWatcher() - ＆gt;可以被认为是主线程

event loop - ＆gt;这是由libuv实现的，所以在这种情况下，工作池线程实际上是libuv线程。

那么，如果没有libuv的线程，工作者如何做某事？

Answer 1

“工作者池”和“libuv的线程池”是相同的。你误解的原因是由于这句话的制定。作为一名非英语母语人士，我明白为什么。

此：

  

文件系统：除fs.FSWatcher()之外的所有文件系统API以及明确同步的API都使用libuv的线程池。

可以这样表达：

  

文件系统：所有文件系统API都使用libuv的线程池，fs.FSWatcher()除外，以及明确同步的线程池。

可以在UV_THREADPOOL_SIZE cli选项的文档中看到更好的表述，如下所示：

  

使用线程池的Node.js API是：

     

  
• ...
  
• 所有zlib API，而不是明确同步的那些