Squeak does not do pre-emptive multitasking.

Michael van der Gulik squeakml at gulik.co.nz
Mon Jun 12 11:07:11 UTC 2006


Firstly, thanks to everybody for their input in this. I'm just picking a 
random post to reply to so don't feel left out :-).

Peter Crowther wrote:
>>From: Michael van der Gulik
>>At the moment I'm just annoyed 
>>that my low priority processes (I assume 10 is low and 80 is high...) 
>>can lock up Squeak. With my 10-process test that I posted, 
>>Squeak will 
>>respond to a alt-., but sluggishly if at all. Theoretically it 
>>shouldn't, but it does.
> 
> 
> Ah, now I seem to recall that's a different problem.  In order to keep
> the speed of bytecode execution high, I recall that not all bytecodes
> check for possible context switches *at all*.  There's then a timer in
> the VM that triggers much more rarely and forces a check, just in case
> of a tight loop that blocks the UI.  Tight loops tend to produce
> bytecode sequences that don't trigger checks, as I recall.  Real-life
> code wouldn't cause the same problems.
 > I think a check is made during at least one of the method call and
 > return sequences.

Yup. It gets checked on message sends and on longUnconditionalJumps. 
I've poked around in the Interpreter and found the methods that check 
for it.

>  Bryce would know more if so, as he'll probably have
> cursed the fact as he was building Exupery!  I accept that the numbers
> would increment more slowly, but a loop of the form "[self increment:
> element]" with increment defined as "counts at: element put: ((counts
> at: element) + 1)" might yield a more responsive system.

I tried that, and it is more responsive! Infact, I wouldn't have been 
able to tell that CPU was at 100% if it weren't for my CPU ticker :-).

Now, the following tweak will also do the trick:

EventSensor eventPollPeriod: 50
Sensor installEventTickler

This causes the event tickler to run 20 times a second rather than 2, 
meaning that at least 20 processes will have a chance to run each 
second. The event tickler calls Delay>>wait, which eventually makes the 
Interpreter do >>wakeHighestPriority, which find the next ready process.

>>- Process has a badly named instance variable - "myList".
> 
> 
> Given that quiescent Processes are held on LinkedLists, it would seem to
> be a reasonable name - what's up with it?

It is a non-descriptive variable name. It stood out because it was the 
only instance variable in Process that I couldn't work out the purpose 
of from its name.

The reason I'm working on this is because I want to modify the VM to be 
able to safely execute foreign (and possibly malicious) code with no 
risk to locally running processes. This is a hard thing to achieve, but 
I need a VM that can handle multitasking, control forkbombs and limit 
the number of objects a piece of remote code would make. Currently I'm 
just trying to have a development environment that doesn't freeze up on 
every bug I introduce :-).

Mikevdg.




More information about the Squeak-dev mailing list