4 ms·

If I recall, this is mainly caused by the shift to USB as the connector du jour. Since it's a poll centric protocol, under heavy load, system responsiveness dec

If I recall, this is mainly caused by the shift to USB as the connector du jour. Since it's a poll centric protocol, under heavy load, system responsiveness decays. Back in the days of P/S 2, where input was interrupt driven, the background tasks would be interrupted by input coming in, ensuring the user could move the mouse around. Now whether they could get the outcome of a click to register is a different story. The click would, but there'd be no guarantee the click handler would execute before background processing resumed, because it'd be considered an event that'd get scheduled after whatever is currently starving the CPU thread.

dezgeg 4y ago
Sure, on the wire USB is a polling protocol. But the polling is done by the host controller hardware, which will raise an interrupt just like PS/2 whenever the device responds to the polling as having data available.
- neonbeige 4y ago
  The polling by the host controller is still limited to happening once every bInterval period as specified by the device, which for mouse/keyboard will be at least a few milliseconds, v.s. the old school PS2 style mice which would send hardware interrupts straight to the processor.
  - dezgeg 4y ago
    Yes, but that sort of 'delay' will be there all the time, with no relation to the system being loaded (like the top commenter is claiming).
taeric 4y ago
The article is about a bug in process destruction, if I'm not mistaken. The mouse bit is a bit of an aside. More of an obvious symptom that something is wrong. Not that interrupt based input processing didn't have some advantages. Just this shouldn't be one of them.
spogbiper 4y ago
As I understand it, the polling is done by the USB controller, not the operating system or anything happening in the system's CPU.
the__alchemist 4y ago
On the MCU (device) side, you can command the poll in a data-received interrupt. Does it not work that way on the PC side? Ie, you never have to really block on the MCU.
- neonbeige 4y ago
  It's the same for the host controller hardware, it exposes different interrupts which the host controller driver can make use of so you don't have to busy-wait. The details depend on the host controller interface the hardware provides though.

dezgeg 4y ago

Sure, on the wire USB is a polling protocol. But the polling is done by the host controller hardware, which will raise an interrupt just like PS/2 whenever the device responds to the polling as having data available.

neonbeige 4y ago
The polling by the host controller is still limited to happening once every bInterval period as specified by the device, which for mouse/keyboard will be at least a few milliseconds, v.s. the old school PS2 style mice which would send hardware interrupts straight to the processor.
- dezgeg 4y ago
  Yes, but that sort of 'delay' will be there all the time, with no relation to the system being loaded (like the top commenter is claiming).

taeric 4y ago

The article is about a bug in process destruction, if I'm not mistaken. The mouse bit is a bit of an aside. More of an obvious symptom that something is wrong. Not that interrupt based input processing didn't have some advantages. Just this shouldn't be one of them.

spogbiper 4y ago

As I understand it, the polling is done by the USB controller, not the operating system or anything happening in the system's CPU.

the__alchemist 4y ago

On the MCU (device) side, you can command the poll in a data-received interrupt. Does it not work that way on the PC side? Ie, you never have to really block on the MCU.

neonbeige 4y ago
It's the same for the host controller hardware, it exposes different interrupts which the host controller driver can make use of so you don't have to busy-wait. The details depend on the host controller interface the hardware provides though.