🚀 go-pugleaf

I see some discussion here about "negligable preemtion / interrupt overhead".

On any CPU, interrupt processing requires a context switch (also required
for preemption and system services).  In the old days, this required
simply the amount of time the CPU required to start the interrupt (and
finish it later) plus the instructions in the interrupt handler.

Nowadays the penalty for an interrupt is much greater, because of
processor caches (or rather, fast processors but memory at the same speed
as before).  The context switch now requires flushing the cache, so the
processor will run slowly for a while as instructions are fetched from
"real memory".  Not only will this slow down interrupt processing
(relative to the estimate from the number of instructions involved), it is
unpredictable.  I estimate that processors are spending the same amount of
real time servicing interrupts as the did years ago, but I may be wrong --
it may take much longer now, due to cache flush and reload.

Deterministic real-time processing is difficult to do with interrupts. 
You really can't tell when all the interrupts will stack up at the same
time, causing the lowest priority interrupt to wait a long time.  Coupled
with the overhead of context switching, this makes interrupt-driven
programming impractical for device controllers (such as, say, a car or a
wheelchair).  Polling with a heartbeat timer is used instead.  The most
time-critical tasks are polled oftenest.  Processing of different tasks is
distributed in time by spreading out the polling.  Such systems can more
easily be proved to work, which is comforting for the person in the
wheelchair who is crossing a busy street.
____________________________________________________________________
TonyN.:'                                              tonyn@tiac.net
      '