Ah, well as one of the authors of that piece of code let me comment,  
assuming Martin and I are talking about the same piece of code.

There is a checkForInterrupts method that is called by the  
interpreter every so often and under certain conditions.

It

- deals with the lowspace pending signal
- ensures VM event polling occurs in a timely manner.
- deals with the interrupt pending signal
- deals with clock rollover
- deals with the finalization logic
- takes any external semaphore index number signal requests off a  
dual queue set and signals the actual semaphore
- executes the next pending process on a semaphore if the semaphore  
should be woken and it's priority is > than the current process.

So if any process that is waiting on a timer, or a semphore is  
signaled, and if the process involved is a *higher* priority than the  
current one we would transfer control.

Now this routine was originally called when we executed a new method,  
and when we  did a long unconditional jump bytecode backwards. Those  
so called  "safe points"

Many years ago when we moved from 25Mhz 68030 motorola macintoshs to  
powerpc machines I discovered that this routine could be called upwards
5,000 a second and contribute to much of the cpu usage of Squeak  
since it was being called on the basis of a number (1000?) being  
decremented.
I altered this logic to ensure it would be called every N  
milliseconds by fiddling with the interruptCheckCounter by  
incrementing, decrementing the value
to reach a steady state to limit the calling frequency to a target  
value.

Later we added the ability to force an interrupt check, say after an  
incremental GC, or after a signal semphore, plus some other  
interesting places to ensure the check for interrupt would very  
quickly process a pending interrupt.

This does not mean the routine is called exactly every N  
milliseconds, rather it's *usually* called every N milliseconds.  How  
many bytecodes that is, is well anyone's guess since reliant on  
method sends, and backward long unconditional jumps.

Exceptions are I believe the Windows VM forces an interrupt check  
every millisecond due to an external timer to ensure it's called more  
closely to the 1 millisecond goal.

On May 1, 2007, at 1:56 PM, Martin v. Löwis wrote:

>> Does the Squeak VM do preemptive scheduling or regular yield style
>> scheduling.  This may sound like a silly question, but I know  
>> Erlang is
>> language that does mainly green threads and they are preemptive in
>> nature.  They accomplish this by allowing a given thread to  
>> execute no
>> more then 100 VM instructions before it is preempted (obviously if a
>> thread makes a primitive call that is a voluntary yield).
>>
>> Does Squeak do this already?
>
> Yes, the Squeak scheduler implements preemptive scheduling. An active
> process is given a quantum of such-and-such many byte codes, and when
> the quantum expires, a scheduling decision is made. The scheduler
> attempts to make each quantum a (tunable) period of time (by default
> 1ms), and adjusts the number of byte code operations to account for
> differences in CPU speed.
>
> Regards,
> Martin
>

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===