操作系统或系统程序如何等待用户输入？
我来自网络编程领域，通常服务器通过指定的方法（get、post 等）设置一个超全局变量，使用户输入到字段中的数据可用。另一种方法是使用 AJAX 将回调方法注册到 AJAX XMLhttpRequest 对象在浏览器通知后将启动的事件（我假设...）。所以我想我的问题是，是否存在某种调度接口，系统程序员的代码必须与之交互以响应用户输入而执行，或者程序员是否直接控制“等待”过程？如果存在调度，操作系统中是否存在等待特定事件发生的循环结构？
我被提示在这里问这个问题，因为我正在上基础编程逻辑课，教授不会回答像这样的“复杂”问题。我的书给出了一个模糊的伪代码示例，例如：
//start
sentinel_val = 'stop';
get user_input;
while (user_input not equal to sentinel_val)
{
// do something.
get user_input;
}
//stop
这个示例让我相信1）如果没有从用户收到输入，循环将继续重复使用旧输入或没有输入的序列“做某事”，直到新输入神奇地出现然后它将再次重复该值或空值。这本书似乎试图使用启动和读取文件的示例来传达程序如何从事件驱动的输入获取数据，不是吗？
我很困惑 ：（
I come from the world of web programming and usually the server sets a superglobal variable through the specified method (get, post, etc) that makes available the data a user inputs into a field. Another way is to use AJAX to register a callback method to an event that the AJAX XMLhttpRequest object will initiate once notified by the browser (I'm assuming...). So I guess my question would be if there is some sort of dispatch interface that a systems programmer's code must interact with vicariously to execute in response to user input or does the programmer control the "waiting" process directly? And if there is a dispatch is there a loop structure in an OS that waits for a particular event to occur?
I was prompted to ask this question here because I'm in a basic programming logic class and the professor won't answer such a "sophisticated" question as this one. My book gives a vague pseudocode example like:
//start
sentinel_val = 'stop';
get user_input;
while (user_input not equal to sentinel_val)
{
// do something.
get user_input;
}
//stop
This example leads me to believe 1) that if no input is received from the user the loop will continue to repeat the sequence "do something" with the old or no input until the new input magically appears and then it will repeat again with that or a null value. It seems the book has tried to use the example of priming and reading from a file to convey how a program would get data from event driven input, no?
I'm confused :(
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在最低级别，计算机的输入是异步的——它通过“中断”发生，这基本上是 CPU 外部的东西（键盘控制器）向 CPU 发送一个信号，表示“停止你正在做的事情并接受这个数据”。 （这很复杂，但这是总体思路）。因此CPU会停下来，抓取击键，并将其放入缓冲区中以供读取，然后继续执行中断之前正在执行的操作。
入站网络流量以及从磁盘读取的结果等也会发生非常类似的情况。
在更高的级别上，它更加依赖于您正在使用的操作系统或框架。
使用键盘输入时，可能会有一个进程（基本上是应用程序）被阻止，等待用户输入。这个“阻塞”并不意味着计算机只是坐在那里等待，而是让其他进程运行。但当键盘输入结果时，它就会唤醒正在等待的人。
从等待过程的角度来看，他们调用了某个函数“get_next_character()”，并且该函数随字符一起返回。等等。
坦率地说，所有这些东西如何联系在一起非常有趣并且易于理解。 :)
At the lowest level, input to the computer is asynchronous-- it happens via "interrupts", which is basically something external to the CPU (a keyboard controller) sending a signal to the CPU that says "stop what you're doing and accept this data". (It's complex, but this is the general idea). So the CPU stops, grabs the keystroke, and puts it in a buffer to be read, and then continues doing what it was doing before the interrupt.
Very similar things happen with inbound network traffic, and the results of reading from a disk, etc.
At a higher level, it gets more dependent on the operating system or framework that you're using.
With keyboard input, there might be a process (application, basically) that is blocked, waiting for user input. That "block" doesn't mean the computer just sits there waiting, it lets other processes run instead. But when the keyboard result comes in, it will wake up the one who was waiting for it.
From the point of view of that waiting process, they called some function "get_next_character()" and that function returned with the character. Etc.
Frankly, how all this stuff ties together is super interesting and useful to understand. :)
操作系统由硬件事件（称为中断）驱动。操作系统不会等待中断，而是执行一条特殊指令，让 CPU 在循环中小睡一下。如果发生硬件事件，就会调用相应的中断。
An OS is driven by hardware event (called interrupt). An OS does not wait for an interrupt, instead, it execute a special instruction to put the CPU a nap in a loop. If a hardware event occurs, the corresponding interrupt will be invoked.
是的，这就是这本书正在做的事情。事实上...unix 操作系统的构建理念是将任何设备的所有输入和输出抽象为如下所示。
实际上，大多数操作系统和硬件都利用中断跳转到我们所谓的子例程来执行低级数据读取，然后将控制权返回给操作系统。
此外，在大多数系统上，许多设备独立于操作系统的其余部分工作，并向操作系统提供高级 API。例如，计算机进程上的键盘端口（或者更好的例子是网卡）会自行中断，然后键盘驱动程序向操作系统提供不同的 api。您可以查看设备标准来了解它们是什么。例如，如果您想了解键盘端口提供的 api，您可以查看 linix 发行版中键盘驱动程序的源代码。
Yes that is what the book is doing. In fact... the unix operating system is built on the idea of abstracting all input and output of any device to look like this.
In reality most operating systems and hardware make use of interrupts that jump to what we can call a sub-routine to perform the low level data read and then return control back to the operating system.
Also on most systems many of the devices work independent of the rest of the operating system and present a high level API to the operating system. For example a keyboard port (or maybe a better example is a network card) on a computer process interrupts itself and then the keyboard driver presents the operating system with a different api. You can look at standards for devices to see what these are. If you want to know the api the keyboard port presents for example you could look at the source code for the keyboard driver in a linix distro.
根据我的理解进行基本解释...
您的
get user_input伪函数通常类似于readLine。这意味着该函数将阻塞，直到读取的数据包含换行符为止。在此之下，操作系统将使用中断（这意味着它不会不必要地处理键盘，而仅在需要时才处理）以允许它在用户按下某些键时做出响应。键盘中断将导致执行跳转到一个特殊的例程，该例程将用来自键盘的数据填充输入缓冲区。然后，操作系统将允许适当的进程（通常是活动进程）使用 readLine 函数来访问此数据。
那里有更多的复杂性，但这是一个简单的视图。如果有人提供更好的解释，我会愿意向高超的知识低头。
A basic explanation based on my understanding...
Your
get user_inputpseudo function is often something likereadLine. That means that the function will block until the data read contains a new line character.Below this the OS will use interrupts (this means it's not dealing with the keyboard unessesarily, but only when required) to allow it to respond when it the user hits some keys. The keyboard interrupt will cause execution to jump to a special routine which will fill an input buffer with data from the keyboard. The OS will then allow the appropriate process - generally the active one - to use
readLinefunctions to access this data.There's a bunch more complexity in there but that's a simple view. If someone offers a better explanation I'll willingly bow to superior knowledge.