Squeak does not do pre-emptive multitasking.

Klaus D. Witzel klaus.witzel at cobss.com
Sun Jun 11 10:00:15 UTC 2006


On Sun, 11 Jun 2006 09:39:30 +0200, 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.

Michael, how about #(9827655 10007232 9951994 9675033 9841446 9849830  
9671092 9782277 9808366 11128384), resulting from
[ | t |
t := TestingScheduler new.
(t numProcesses: 10) inspect] fork

Some time ago I was thinking about having automagic timesharing in Squeak

- http://people.squeakfoundation.org/article/48.html

With the forked block from above and my timesharing VM hack, the GUI is no  
longer locked up.

> 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*.

The change I made to the VM is, after #quickCheckForInterrupts

	"check for possible interrupts at each real send"
	checkCounter _ interruptCheckCounter - 1.
	self quickCheckForInterrupts.
	"kwl 10/15/2005 - time share the CPU"
	(checkCounter = 1)
		ifTrue: [self primitiveYield]

> 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.

Yes, in #executeNewMethod a #quickCheckForInterrupts is done. Another one  
is done in #longUnconditionalJump, but I didn't touch because changing  
#executeNewMethod was already sufficient.

> 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.

FWIW the difference between non forked and forked execution was just about  
1%.

/Klaus




More information about the Squeak-dev mailing list