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