[squeak-dev] Re: Suspending process fix
Andreas Raab
andreas.raab at gmx.de
Tue Apr 28 17:53:10 UTC 2009
Andreas Raab wrote:
> I'll settle for a definition of "correct" behavior
> in the presence of asynchronous interrupts since it is really not clear
> to me what you mean when you say "correct".
I had a thought about that this morning. One possible definition of
"correct" in this context may mean that a process in a "frozen" state
(to disambiguate from a current "suspended" state) simply does not
advance its pc but behaves identical to an unfrozen process in all other
respects.
The effect can be simulated (within reason) by something that simply
drops the priority of a process to below the idle process' priority so
that it just doesn't get any computational resources.
The point being that a freezing a process doesn't even touch the
suspended list. You could implement this for example by using negative
priorities to indicate that a process is frozen, along the lines of:
Process>>isFrozen
"Answer if the process is frozen"
^priority < 0
Process>>freeze
"This needs to be a primitive"
self isFrozen ifTrue:[^self].
priority := priority negated.
Process>>unfreeze
"This needs to be a primitive"
self isFrozen ifFalse:[^self].
priority := priority negated.
Changing synchronousSignal: not to allow frozen processes to become
runnable (i.e., test for negative priority and just ignore it if that's
the case) would achieve most of what you need (modulo the primitives for
freeze/unfreeze).
Obviously the effects will be "interesting" (to say the least) if you
freeze a process on its way into a mutex since that process will indeed
hold the mutex until such a point that it becomes unfrozen. But I guess
that is kind of what you were asking for after all ;-)
Cheers,
- Andreas
More information about the Squeak-dev
mailing list
|