关于 node.js 内部异步 I/O 机制的困惑 [英] Confusion about node.js internal asynchronous I/O mechanism

问题描述

1. 我了解到 node.js 在内部使用 libeio 在 *nix 平台上使用线程池执行异步文件 I/O，对吗?
2. 异步网络 I/O 怎么样?是由 libev 完成的吗?还有线程池吗?
3. 如果内部有线程池，它如何比传统的每请求一个线程模型更高效?每个 I/O 请求是一个线程吗?
4. Windows 上的机制是什么?我知道它是由 IOCP 完成的，并且有一个内核级线程池，对吗?
5. 为什么 linux 还没有像 windows IOCP 这样的原生完全 AIO 机制?将来会有吗?

1. I have learned that node.js use libeio internally to perform async file I/O, with thread pool, on *nix platform, am I right?
2. What about async network I/O? Is it done by libev? Is there also a thread pool?
3. If there is thread pool inside, how could it be more efficient than traditional one-thread-per-request model? And is it one thread per I/O request?
4. And what's the mechanism on windows? I know it's done by IOCP, and there's a kernel level thread pool, right?
5. Why linux doesn't have a native completely AIO mechanism like windows IOCP yet? Will it have in future?

根据changchang的回答更新:

Update according to changchang's answer:

1. 我快速浏览了源代码@changchang 已经给出，发现默认线程池大小可以通过UV_THREADPOOL_SIZE重置，我想知道在什么情况下会使用这个?
2. 我也发现 getaddrinfo 使用了这个线程池，除了 fs 还有其他的吗?如果所有同步作业都将在此线程池中完成，那么默认大小 '4' 是否足够?
3. 据我所知，node.js 进程中将有 6 个基本线程:1 个 V8 线程(事件循环，用户 javascript 代码运行的地方)、1 个 libuv 事件循环和线程池中的 4 个，对吗?

4. 我怎样才能在我的 shell (Ubuntu) 中看到这些线程?我使用 ps -eLf |grep 节点 |grep -v grep 只看到两个:

1. I took a quick view at the source code @changchang have given, found that the default thread pool size can be reset by UV_THREADPOOL_SIZE, I'm wondering in which case this will be used?
2. I also found getaddrinfo use this thread pool, is there any more except fs? And if all sync jobs will be done in this thread pool, is the default size '4' enough?
3. As my understanding now, there will be 6 basic threads in node.js process: 1 V8 thread(event loop, where user javascript codes runs), 1 libuv event loop, and 4 in thread pool, am I right?

4. And how can I see these threads in my shell(Ubuntu)? I use ps -eLf | grep node | grep -v grep only saw two:

root 16148 7492 16148 0 2 20:43 pts/26 00:00:00 ./bin/node/home/aaron/workspace/test.js
根 16148 7492 16149 0 2 20:43 pts/26 00:00:00 ./bin/node/home/aaron/workspace/test.js

root 16148 7492 16148 0 2 20:43 pts/26 00:00:00 ./bin/node /home/aaron/workspace/test.js
root 16148 7492 16149 0 2 20:43 pts/26 00:00:00 ./bin/node /home/aaron/workspace/test.js

推荐答案

1. 首先，libuv 已经从其中移除了 libeio.但正如您提到的那样，它确实使用像 libeio 这样的线程池来执行异步文件 I/O.

1. First of all, libuv has removed the libeio from it. But it does perform async file I/O with a thread pool like libeio just as you mentioned.

libuv 也删除了 libev.它基于不同平台的异步I/O接口进行异步网络I/O，例如epoll、kqueue和IOCP，无需一个线程池.uv 的主线程上有一个事件循环，它轮询 I/O 事件并处理它们.

libuv also removes libev. It does the async network I/O based on the async I/O interfaces in different platforms, such as epoll, kqueue and IOCP, without a thread pool. There is a event loop which runs on the main thread of uv which polls the I/O events and processes them.

libuv 里面的线程池是一个固定大小的线程池(4 在类似 uinx 的系统中).它起到了任务队列的作用，通过在请求增加时无限地生成线程来避免系统资源耗尽.

The thread pool inside libuv is a fixed size thread pool (4 in uinx like system). It performs a task queue role and avoids the exhaustion of the system resources by generating threads indefinitely when the requests increase.

这篇关于关于 node.js 内部异步 I/O 机制的困惑的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！