Generally, the way input devices work is, when they are used, an interrupt (IRQ) is generated. (The only devices not like this would be the old PC-style game port, and I'm not sure how the operating system deals with that.)
IRQs cause a CPU core to immediately jump to another place - the IRQ handler then needs to save the state of the CPU, deal with the device (such as capture the input and
report it through whatever OS mechanism), and then return from interrupt.
IRQs also cause the CPU core to disable further interrupts. So for a brief period of time, it can't do anything else or be interrupted again, even if a device tries to trigger another interrupt. PCs have APIC hardware that is heavily involved in controlling, distributing, and managing interrupts, so consider this an oversimplification, though. (For example, I think the APIC can remember if another IRQ comes in while the CPU is processing one, and immediately trigger it on the CPU side right after the CPU tells the APIC "hey, I'm done with this IRQ.")
Windows deals with interrupts through something called a "deferred procedure call" - it does the minimum it needs in this "interrupted" state to get the device's request acknowledged and then hands off the rest of the processing to the actual device driver responsible, which takes care of it when the scheduler finds it convenient or necessary.
So because of this, Windows should acknowledge each device-caused IRQ unless it's stuck in an interrupted state somewhere due to a faulty driver, faulty device, or major corruption of operating system binaries. The DPCs which actually cause Windows to do something interesting with the device request may be what gets delayed.
The general way for an operating system to force a process to give up the CPU is to have a hardware timer that, when it runs out, causes an IRQ. The same type of IRQ as described above. IRQs always cause the CPU to switch to kernel mode. So at that point, the kernel has control and can switch to another process. Without this mechanism, you are wholly dependent on the process to tell the operating system when it is done, and this is what's called "cooperative multiltasking" as opposed to "pre-emptive multitasking."