A couple of years ago I had a patch that measures smalltalk process  
dispatch time in milliseconds
It added that to a instance variable in the Processes instance so you  
could accurately see what was happening on
a process level. The current process browser does that but not to the  
same degree of accuracy.

You'll find the only way you  can accurately measure and most likely  
dispatch on a time share basis is to change the
logic in Interpreter >>resume:  Plus perhaps tinker with  
Interpreter>>checkForInterrupts which is call on a 1-5ish millisecond  
basis on most
platforms to enforce rules about time share dispatching.

PS someone might suggest a change to resume: which might allow lower  
priority threads a chance to run from time to time to
prevent a runaway high priority thread?

On Nov 10, 2003, at 3:43 PM, Eric Merritt wrote:

>
>>
>> I don't recall. The preemption is pretty simple: if
>> there's a higher priority
>> process that's ready to run when the VM checks, the
>> current process gets
>> suspended. Which puts it at the end of the list for
>> that priority.
>
>  I realize that, but if you have an extra process
> handling the thread priorities you need someway to
> make the premption fair. For example in either erlang
> or mozart-oz (I forget which) preemption happens after
> 500 reductions. In other langauges its so many byte
> codes or so many message sends. Its all just a scheme
> to make sure processes all get a equal share of the
> processor.
>
>> I don't know why you'd need anything fancier than
>> that for experimenting with.
>
>  For experimenting a time slice would work well
> enough.--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===