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

查看:106
本文介绍了关于node.js内部异步I / O机制的困惑的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述


  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?

根据昌昌的回答更新:


  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

root 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 in uinx like system )。它执行任务队列角色,并通过在请求增加时无限期地生成线程来避免系统资源耗尽。

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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆