3 ms·
Interrupts vs polling hardware is in the OS. Regardless of how the OS handles IO, user code can either poll the OS or have the OS wakeup a thread when there's
by anamax 5y ago
Interrupts vs polling hardware is in the OS.
Regardless of how the OS handles IO, user code can either poll the OS or have the OS wakeup a thread when there's a change, such as data for a blocking call.
- egberts1 5y agoAs a long-time embedded engineer, I violently recoiled at the over-generalization: “in the OS”. Perhaps “user-land” is that missing aspect. Think how zero-buf embedded network software architect deal with no interrupt and no context switching.
- anamax 5y agoEven in embedded land, there is code that manages IO devices. And, in much/most embedded systems, there is some separation of concerns, if only because such systems do multiple things. Data comes in. Via some combination of device configuration and device handling code, it gets put somewhere. Meanwhile, there's some other code that will process said data, but the system is doing lots of other things. There are two ways to know when to run said "other code". The code that handled the hardware can start said other code or something else in the system can ask "is there new data" periodically. One implementation of "can start" is waking up a thread. Note that the "interrupt vs polling" decision for the "handle hardware" code does not dictate which way is used to know when to run said other code.