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
|