Careful now in the deep dark voids of tweak we discovered one day that  
it was incrementing process priority in the semaphore logic, this led  
to the interesting
behavior that the processor priority could reach 327...

However *IF* a walkback occurred it the fellow responsible for  
launching the debug logic would create a fork off a new process at the  
same priority as the
current process, however in the in the new process logic logic there  
was a sanity check for process priority numbers, and it would go boom,  
and the house of cards would sliently fall flat. Er since it's in the  
debug logic it *was* rather hard at first to determine what was going  
on...

I do wonder.

mmm latest pharo image

  [1 == 0] forkAt: 999.

oops..

I wonder what tweak images do now?


On 29-Apr-09, at 12:44 PM, Eliot Miranda wrote:

>
> Just to clear-up any confusion, the current VM is not limited to 80;  
> it will use any size.
>
> To shorten the list iteration I've done the following, first in  
> VisualWorks and now in the StackVM and Cog.  Simply maintain a "high- 
> tide" which is the highest current runnable process priority.  The  
> list search only has to start from this value rather than the  
> highest priority, which most of the time saves scanning 40 empty  
> lists on every wakeHighestPriority.
>
> I've attached the changes (just two methods) except for the  
> initialization of highestRunnableProcessPriority to zero in the  
> relevant initializeInterpreter:.
>

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