[squeak-dev] Re: New scheduling policies [Was: Re: Re: Suspending
John M McIntosh
johnmci at smalltalkconsulting.com
Wed Apr 29 22:03:18 UTC 2009
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
I do wonder.
mmm latest pharo image
[1 == 0] forkAt: 999.
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:
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
More information about the Squeak-dev