An analysis of interrupt behavior

Andreas Raab andreas.raab at gmx.de
Fri Apr 1 08:34:55 UTC 2005


Tim Rowledge wrote:
> Andreas Raab <andreas.raab at gmx.de> wrote:
> 
>>Yes. Easily so. The "major safeguard" that Tim referred to is actually a
> 
> Not me so far as I can tell...

Then this must be a clear case of identity theft ;-))

http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-May/078325.html

> The amusing part is that the semaphore used for low space has the lowspace
> process on its list and we remove it as part of signalling. Maybe if we stuck
> the active process on the end as some 'helpful context' it would make life
> simpler. Or a subclass of Semaphore with a more explicit ivar(s) if we want to
> reduce confusion potential.

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.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list