Klaus D. Witzel writes:

 > > There's then a timer in
 > > the VM that triggers much more rarely and forces a check, just in case
 > > of a tight loop that blocks the UI.  Tight loops tend to produce
 > > bytecode sequences that don't trigger checks, as I recall.  Real-life
 > > code wouldn't cause the same problems.
 > >
 > > I think a check is made during at least one of the method call and
 > > return sequences.
 > 
 > Yes, in #executeNewMethod a #quickCheckForInterrupts is done. Another one  
 > is done in #longUnconditionalJump, but I didn't touch because changing  
 > #executeNewMethod was already sufficient.

quickCheckForInterrupts is the place. It only does a full check
occasionally. At every call it decrements a counter and if the
counter is zero it does a full check. This is because the full
check is slow.

 > > Bryce would know more if so, as he'll probably have
 > > cursed the fact as he was building Exupery!  I accept that the numbers
 > > would increment more slowly, but a loop of the form "[self increment:
 > > element]" with increment defined as "counts at: element put: ((counts
 > > at: element) + 1)" might yield a more responsive system.

I did curse the fact, but mostly because of subtle bugs. The
first really hard bug with Exupery was when a process was
switched due to an interrupt. Exupery didn't realise then and
tried to execute the native code for the old process using the
CompiledMethod of the new process, this lead to a crash.

Bryce