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
|