Basically, a RTOS can guarantee it can service an IRQ (interrupt request) in a specific (usually low) timeframe. Standard operating systems do not have such a guarantee.
In most modern systems, most devices can generate an IRQ. This causes the CPU to stop (i.e. be interrupted of) what it's doing and run an interrupt service program. The idea is that this service program does whatever the device needs, i.e. gets data off of the device and into RAM, tells the device what to do next, etc.
On x86, since it has only 1 IRQ line on the CPU, when it receives an interrupt, further interrupts are automatically disabled (except for NMI, RESET, and SMI) until the CPU acknowledges the interrupt source and reenables them. So good device drivers under standard i386/amd64 Windows will do minimal processing in this state, just enough so that it's OK to reenable interrupts, and then defer complete processing of the interrupt until later (because the system can technically only service 1 interrupt per CPU core at a time). I'm not sure but I believe Linux does the same. Nonetheless, there is no hard guarantee made of the time that the interrupt will be serviced under.
For most PC devices, such as disks, keyboards, NICs, if there is a slight delay servicing their IRQ, nothing bad will happen other than a loss in performance. This can be more of a problem for devices such as audio and video input, where the device doesn't buffer anything and the PC really needs to keep up with the incoming stream of data.