Is the processor wasted waiting for keyboard input? (Total)
I've wandered if there is a way where the OS doesn't have to cycle endlessly for keyboard (or other input device) input, and if there is any OS using that. I can't believe we need to waste time on the bike to wait for input, why can't it do something once instead of the machine waiting for action.
Shortly speaking:
How does keyboard input work - polling or interrupts?
source to share
Most modern programs do not receive input into a loop as you describe. You can use event handling or interrupts to avoid wasted loops.
source to share
All device input from all devices on all Linux operating systems is interrupt based. Waiting busy (active polling) is not used for data.
Windows is probably also interrupt driven. (Windows has a DOS legacy hiding within it - polling can still happen there.)
All Linux works the same. The kernel waits for interrupts, suspends interrupts, and checks the scheduler to handle the highest priority interrupt. Process scheduling always has a lower priority than interrupt scheduling.
Keyboard interrupts are handled by a driver that buffers information. A window manager (like Gnome) fetches stuff from the buffer to create a keyboard interrupt stream.
You can buy many really good books on OS design that cover the relationship between device drivers and the kernel. Start at http://lwn.net/Kernel/LDD3/
Hourly Interrupts, BTW, are how the scheduling of a process occurs. When there is no device activity, the clock will interrupt periodically, forcing the kernel to watch the graph, possibly changing which process is running. A process that uses a lot of CPU takes priority. A process that does a lot of I / O spends most of its time waiting for I / O to complete, so the priority is raised.
Edit
In addition, there are - sometimes - DMA devices that bypass kernel interrupt handling for block transfer of bytes. An interrupt initiates a transfer, but the device lives on the bus and accesses a memory directory. Video displays, disks (and in the old days, network devices) can be DMA. Keyboards, however, are so small that DMA is not a handy optimization.
source to share
This usually happens as follows:
- the process (application) makes a (blocking) system call meaning "get me a push"
- The OS puts the process in an "I / O pending" state, discarding it from the CPU
- ... time passes, other processes are running successfully, discs are spinning, flashes are flashing ... User
- presses a key, an interrupt is generated
- OS receives an interrupt, reads a key press, checks if there are any processes waiting for input of that particular device (keyboard)
- finds a waiting process, puts it in the "runnable" state.
- when there is a free processor, the process gets it and resumes its execution after a system call
So there is no polling (active waiting) at any stage.
Edit. As far as I can remember, the Linux kernel sometimes switches to polling for devices that would otherwise flood it with interrupts (I think the fast NIC is receiving a huge amount of packets). In these conditions, it saves processor time, and does not waste it - the OS receives a large chunk of data with one poll, and not many small chunks with many interrupts. When the poll no longer receives any data, the OS switches back to idle-intterupt.
source to share
You can simply check for keyboard input with a non-blocking function, and if not, then together using sleep (1) or a similar construct.
You do not need wasting the processor you planned.
A fully possible keyboard lock function can give on its own and the OS will only resume the thread once it is entered.
source to share
The only time I've seen a survey is when you're working with a raw DirectX input device (as they are outside the scope of typical H / W architecture). You must poll these devices (which can be mice, keyboards, joysticks, gamepads, etc.) to get their current state. Like everyone else, a typical keyboard is handled through interrupts.
source to share
USB devices cannot generate interrupts and are therefore processed by the operating system many times per second. Gamers sometimes like to increase this polling rate to get a more responsive mouse.
Games often use polling to process input, but other applications are much more likely to sleep until the operating system sends them input.
source to share