Ausome, thanks for the break down.  It sounds like all processes get about 
the same quatum at the moment.  I wonder what would happen with an "event 
driven" scheduler (I believe that's what it's called) [1].  I suppose for 
what most people are using Squeak for at this point it wouldn't matter so 
much, but if Squeak ever started doing massive green threads it might be 
more important.

[1] By this I mean the kind of scheduler (I believe invented by Sun) that 
gives high priority processes a very short quantum and very low priority 
processes a longer one (400ms is max as I recall).  If a process actually 
uses it's whole quantum it gets dropped in priority and if it yields early 
it gets promoted to higher priority.  With this style of scheduling, 
interactive processes always go quickly to top (non-real time) priority 
because they spend most of their time waiting on IO.

>From: John M McIntosh <johnmci at smalltalkconsulting.com>
>Reply-To: johnmci at smalltalkconsulting.com,The general-purpose Squeak 
>developers list<squeak-dev at lists.squeakfoundation.org>
>To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>Subject: Re: Preemptive scheduling
>Date: Tue, 1 May 2007 14:54:12 -0700
>
>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
>======================================================================== 
>===
>
>
>

_________________________________________________________________
Mortgage refinance is Hot. *Terms. Get a 5.375%* fix rate. Check savings 
https://www2.nextag.com/goto.jsp?product=100000035&url=%2fst.jsp&tm=y&search=mortgage_text_links_88_h2bbb&disc=y&vers=925&s=4056&p=5117