异步的NodeJS I / O执行 [英] NodeJS Asychronous I/O Execution
问题描述
据我了解，虽然有显然是一个'助手'线程，Node.js的在一个线程中运行，因此，在事件循环堆栈每个操作运行此起彼伏等操作，将排队，而节点执行异步在后台I / O，这样服务器能够同时无需创建浪费的多线程，则I / O完成后做非阻塞I / O执行其他操作与它相关的回调被拉入事件循环队列，这是有关节点的一件大事。
As far as I understand, although there is apparently a 'helper' thread, Node.js runs in a single thread, therefore, each operation in the Event Loop stack runs one after another and other operations and queued while Node performs asynchronous I/O in the background, this way the server is able to perform other actions while doing non-blocking I/O without the need to create wasteful multiple threads, the I/O is finished and the it's associated callback is pulled into the Event Loop queue, and that's the big thing about Node.
然而，在许多文章中，我已经准备好了，目前尚不清楚，如果异步I / O操作与其它I / O操作并行运行的I / O一个单独的线程或进程，或如果每个请求的I / O操作运行一次陆续在一个辅助线程，而事件循环执行其他操作。和阅读这句话后，一切都运行在平行除了你的code这让我更加迷惑。
However, in many articles I've ready, is not clear if asynchronous I/O operations run in parallel with other I/O operations in I/O a separate thread or process or if each requested I/O operation runs one after another in a helper thread while the Event Loop performs other actions. And after reading the phrase "Everything runs in parallel except your code" this makes me even more confuse.
问题是，多线程还是多线程没有？如果每个异步操作在一个单独的线程中运行，是不是有使用尽可能多的资源作为Apache服务器会吗？
The question is, multithread or not multithread? If each asynchronous operation runs in a separate thread, doesn't it have use as much resources as an Apache server would?
推荐答案
节点是，实际上，非多线程的。在异步性远不止节点比libuv更深，更深，而且比设备更深层（的epoll ，的kqueue ， IOCP 等）libuv使用。
Node is, essentially, non-multithreaded. The asynchronicity goes deeper than Node, deeper than libuv, and even deeper than the facilities (epoll, kqueue, IOCP, etc.) that libuv uses.
在内核得到一个异步请求时，它不会引发执行另一个线程。相反，它增加了一个简单的列表的事情需要提防。如果一个过程使网络读取请求，例如，内核将使该列表中的条目。这有点像哎，下次还有看起来像这样的读请求，让进程知道这件事。此条目后，内核返回控制的过程和双方继续他们的快乐的方式。那生存的唯一事情是名单上的数据。
When the kernel gets an async request it does not fire up another thread of execution. Instead, it adds it to a simple list of "things to watch out for." If a process makes a network read request, for instance, the kernel will make an entry on that list. It's something like "hey, next time there is a read request that looks like this, let the process know about it." After making this entry, the kernel returns control back to the process and both go on their merry way. The only thing that survives is the data on the list.
内核通过硬件中断的网络阅读活动的通知。使用中断时，猛拉处理器内核进入一个特殊的循环 - 停止任何东西它做的时刻 - 并告诉它有关的事件。内核然后针对其未完成的请求的列表，并检查（在KEVENT AIO情况）发送一个类似的中断（在一信号的形式）到处理让它知道有关网络读取。所以，没有线程。只是中断。
The kernel is informed of a network read event via hardware interrupts. Using an interrupt, the processor yanks the kernel into a special loop -- stopping anything it's doing at the moment -- and tells it about the event. The kernel then checks against its list of outstanding requests, and (in the kevent AIO case) sends a similar interrupt (in the form of a signal) to the process to let it know about the network read. So, no threads. Just interruptions.
好了，这是一个有点简单化的：在非AIO KEVENT和epoll的情况下，内核盯着网络阅读它只会把它放在一个事件清单。这个过程会周期性地检查事件列表，看看是否有进来吧。
Well, this is a bit of a simplification: in the non-AIO kevent and epoll cases, after the kernel gets a network read it'll just put it on an event list. The process periodically checks that event list to see if something came in for it.
另外，从内核来看，这是怎么回事呢I / O工作。最大的区别是，内核不要求进程等待内核取回它。
Also, from the kernel view, this is how all I/O works. The big difference is that the kernel isn't requiring the process to wait for the kernel to get back to it.
有实际上是多了几分复杂在libuv为非网络请求（DNS请求，这是网络请求的特殊的，痛苦的形式）是由线程来处理。这是因为，可以使这些异步内核设施一般没有那么大，如果它们存在的。
There is actually a little more complexity in libuv as non-network requests (and DNS requests, which are special, painful forms of network requests) are handled by threads. This is because the kernel facilities for making those asynchronous are generally not so great, if they exist at all.
这篇关于异步的NodeJS I / O执行的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
