An analysis of interrupt behavior

David T. Lewis lewis at mail.msen.com
Sat Apr 9 13:40:42 UTC 2005


On Fri, Apr 01, 2005 at 12:34:55AM -0800, Andreas Raab wrote:
> 
> I think it's a little more complex than that. It would be nice if we 
> could define a few reliable test cases to spec out what it actually is 
> that we think ought to work. I'll throw in the following:
> 
> * "[true] whileTrue" - we must be able to interrupt this
> * "[[true] whileTrue] forkAt: Processor userSchedulingPriority + 1" - 
> again we must be able to interrupt that
> * "Smalltalk stackOverflow" - we must be able to recover from that
> * "[Smalltalk stackOverflow] forkAt: Processor userSchedulingPriority + 
> 1" - again we must be able to recover from that
> 
> If there are more, please add.

Some variations to add the above list:

1) Each case must be interruptable in Morphic and in MVC.
2) Each case must be interruptable either with or without the event tickler
   running (a high priority process that may become schedulable while a low
   space condition is being detected in the VM).
3) Each case must be interruptable with a fixed size object memory, or with
   a dynamically expanding object memory (varies by platform, "-memory 10m"
   flag for a Unix VM).
4) Each case must be interruptable if the user hits the interrupt key
   multiple times in succession.

Variation #4 fails in Morphic for the "[true] whileTrue" tests going back
to at least Squeak 3.6.

The "[[true] whileTrue] forkAt: Processor userSchedulingPriority + 1" fails
in MVC going back to at least Squeak 3.6.

Dave




More information about the Squeak-dev mailing list