还有其他方法可以实现“监听"功能吗?功能没有无限的while循环? [英] Is there any other way to implement a "listening" function without an infinite while loop?
问题描述
我一直在思考诸如React之类的代码和库，这些代码和库会在事件发生时自动对它们做出反应，并且想知道如何在较低级别的C ++和机器代码中实现所有这些功能.
I've been thinking a lot about code and libraries like React that automatically, well, react to events as they happen, and was wondering about how all of that is implemented at the lower levels of C++ and machine code.
我似乎无法弄清楚是否可以通过其他线程上运行的while循环来实现类似事件监听器的其他方式.
I can't seem to figure out any other way something like an event listener could be implemented with if not with a while loop running on another thread.
那么这一切都在幕后吗?只是一路循环下去?例如，例如RethinkDB，它自己宣传为实时数据库"，其中具有 repubsub 库. 订阅"方法是否只是在幕后使用while循环实现的?我似乎找不到任何信息.
So is that all this is under the hood? Just while loops all the way down? Like, for example, RethinkDB, which advertises itself as a "realtime database" that has the repubsub library. Is the "subscribe" method just implemented using a while loop under the hood? I couldn't seem to find any information on that.
就像插座，东西一样.当计算机正在侦听"用于套接字连接的端口时，该计算机是否正在运行类似以下内容的东西:
Like, sockets and stuff, too. When a computer is a "listening" on a port for a socket connection, is that computer just running something like:
while(1) {
if (connectionFound) {
return True;
}
}
或者我缺少什么?
推荐答案
我将这个问题的答案写在另一个答案中.通常，我会以重复并指向的方式来关闭此问题答案，但这是一个非常不同的问题.另一个问题是关于javascript性能的问题.为了回答这个问题，我必须首先写下这个问题的答案.
I've written the answer to this question as an aside in another answer. Normally I'd close this question as a duplicate and point to that answer however this is a very different question. The other question asked about javascript performance. In order to answer that I had to first write the answer to this question.
因此，我将要做一些通常不应该做的事情:我将部分答案复制到另一个问题上.所以这是我的答案:
As such I'm going to do something that's not normally supposed to be done: I'm going to copy part of my answer to another question. So here's my answer:
javascript和node.js等待的实际事件根本不需要循环.实际上，它们需要0％的CPU时间.
Actual events that javascript and node.js waits on requires no looping at all. In fact they require 0% CPU time.
硬件
如果我们真的需要了解节点(或浏览器)内部的工作方式，那么不幸的是，我们必须首先了解计算机的工作方式-从硬件到操作系统.是的，这将是一次深潜，请耐心等待..
If we really need to understand how node (or browser) internals work we must unfortunately first understand how computers work - from the hardware to the operating system. Yes, this is going to be a deep dive so bear with me..
这是一个伟大的发明，也是一个潘多拉魔盒-Edsger Dijkstra
It was a great invention, but also a Box of Pandora - Edsger Dijkstra
是的，以上引用来自同一"Goto认为有害".迪克斯特拉.从一开始就将异步操作引入计算机硬件被认为是一个非常困难的话题，即使对于业内的一些传奇人物而言.
Yes, the quote above is from the same "Goto considered harmful" Dijkstra. From the very beginning introducing asynchronous operation to computer hardware was considered a very hard topic even for some of the legends in the industry.
引入了中断以加快I/O操作.硬件无需将软件以无限循环的方式轮询某些输入(从而节省了CPU时间来完成有用的工作)，而是向CPU发送信号以告知事件已发生.然后，CPU将挂起当前正在运行的程序，并执行另一个程序来处理中断-因此我们将这些函数称为中断处理程序.并且处理程序" 一词一直在堆栈中一直停留在GUI库中，GUI库将回调函数称为事件处理程序".
Interrupts was introduced to speed up I/O operations. Rather than needing to poll some input with software in an infinite loop (taking CPU time away from useful work) the hardware will send a signal to the CPU to tell it an event has occurred. The CPU will then suspend the currently running program and execute another program to handle the interrupt - thus we call these functions interrupt handlers. And the word "handler" has stuck all the way up the stack to GUI libraries which call callback functions "event handlers".
如果您不熟悉维基百科，并且想了解更多信息，维基百科实际上有一篇不错的文章:
Wikipedia actually has a fairly nice article about interrupts if you're not familiar with it and want to know more: https://en.wikipedia.org/wiki/Interrupt.
如果您一直在关注，您会注意到中断处理程序的概念实际上是回调.您将CPU配置为在事件发生后的某个时间调用函数.因此，即使回调也不是一个新概念-它比C还要老.
If you've been paying attention you will notice that this concept of an interrupt handler is actually a callback. You configure the CPU to call a function at some later time when an event happens. So even callbacks are not a new concept - it's way older than C.
中断使现代操作系统成为可能.没有中断，CPU将无法暂时停止程序以运行OS(嗯，这是协作式多任务处理，但现在暂时忽略它).操作系统的工作方式是在CPU中设置硬件计时器以触发中断，然后告诉CPU执行程序.正是这种定时计时器中断使您的操作系统运行.
Interrupts make modern operating systems possible. Without interrupts there would be no way for the CPU to temporarily stop your program to run the OS (well, there is cooperative multitasking, but let's ignore that for now). How an OS works is that it sets up a hardware timer in the CPU to trigger an interrupt and then it tells the CPU to execute your program. It is this periodic timer interrupt that runs your OS.
除计时器外，操作系统(或更确切地说是设备驱动程序)还为I/O设置了中断.发生I/O事件时，操作系统将接管您的CPU(或多核系统中的一个CPU)，并检查其数据结构以处理下一步处理I/O的过程(这称为抢先式多任务处理.
Apart form the timer, the OS (or rather device drivers) sets up interrupts for I/O. When an I/O event happens the OS will take over your CPU (or one of your CPU in a multi-core system) and checks against its data structure which process it needs to execute next to handle the I/O (this is called preemptive multitasking).
用于存储到网卡的所有形式的键盘和鼠标都会使用中断来告知系统要读取的数据.没有这些中断，监视所有这些输入将占用大量CPU资源.中断是如此重要，以至于它们通常被设计成USB和PCI等I/O标准.
Everything form keyboard and mouse to storage to network cards use interrupts to tell the system that there is data to be read. Without those interrupts, monitoring all those inputs would take a lot of CPU resources. Interrupts are so important that they are often designed into I/O standards like USB and PCI.
现在我们对此有一个清晰的了解，我们可以了解节点/javascript如何实际处理I/O和事件.
Now that we have a clear picture of this we can understand how node/javascript actually handle I/O and events.
对于I/O，各种操作系统具有提供异步I/O的各种不同API-从Windows上的重叠I/O到Linux上的轮询/轮询，再到BSD上的kqueue到跨平台select(). Node内部使用libuv作为这些API的高级抽象.
For I/O, various OSes have various different APIs that provide asynchronous I/O - from overlapped I/O on Windows to poll/epoll on Linux to kqueue on BSD to the cross-platform select(). Node internally uses libuv as a high-level abstraction over these APIs.
这些API的工作方式相似，但细节有所不同.本质上，它们提供了一个函数，当调用该函数时，它将阻塞您的线程，直到OS向其发送事件为止.因此，是的，即使非阻塞I/O也会阻塞您的线程.这里的关键是阻塞I/O将在多个位置阻塞您的线程，但非阻塞I/O将仅在一个位置(您等待事件的位置)阻塞您的线程.
How these APIs work are similar though the details differ. Essentially they provide a function that when called will block your thread until the OS sends an event to it. So yes, even non-blocking I/O blocks your thread. The key here is that blocking I/O will block your thread in multiple places but non-blocking I/O blocks your thread in only one place - where you wait for events.
请查看我对另一个问题的答案，以获取有关此类API在C/C ++级别如何工作的更具体示例:
Check out my answer to this other question for a more concrete example of how this kind of API works at the C/C++ level: I know that callback function runs asynchronously, but why?
对于GUI事件(如按钮单击和鼠标移动)，只需跟踪鼠标和键盘中断，然后将其转换为UI事件即可.这样可以释放您需要知道按钮，窗口，图标等位置的软件表格.
For GUI events like button click and mouse move the OS just keep track of your mouse and keyboard interrupts then translate them into UI events. This frees your software form needing to know the positions of buttons, windows, icons etc.
这允许您执行的操作是以面向事件的方式设计程序.这类似于中断使OS设计人员实现多任务处理的方式.实际上，异步I/O是针对框架的，而中断是针对OS的.它允许javascript花费恰好0％的CPU时间来处理(等待)I/O.这就是使异步代码快速的原因-并不是真的更快，但不会浪费时间等待.
What this allows you to do is design your program in an event-oriented manner. This is similar to how interrupts allow OS designers to implement multitasking. In effect, asynchronous I/O is to frameworks what interrupts are to OSes. It allows javascript to spend exactly 0% CPU time to process (wait for) I/O. This is what makes asynchronous code fast - it's not really faster but does not waste time waiting.
此答案的期限很长，因此我将保留指向该主题的其他问题的答案的链接:
This answer is fairly long as is so I'll leave links to my answers to other questions that's related to this topic:
Node js的体系结构和性能(注意:此答案提供了关于事件和线程之间关系的一些见解-tldr:操作系统在内核事件之上实现线程)
Node js architecture and performance (Note: This answer provides a bit of insight on the relationship of events and threads - tldr: the OS implements threads on top of kernel events)
这篇关于还有其他方法可以实现“监听"功能吗?功能没有无限的while循环?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
