[squeak-dev] Processor activeProcess suspendedContext notNil during simulation

christoph.thiede at student.hpi.uni-potsdam.de christoph.thiede at student.hpi.uni-potsdam.de
Thu Dec 30 19:08:48 UTC 2021

Hi all,

the docs on suspendedContext in the Process class comment say:

	if nil, then I am either the active process or I have been terminated.  If not nil it is the Context at the hot end of my stack

To me, this would indicate the following invariant:

	self assert: Processor activeProcess suspendedContext isNil.

However, this invariant is violated if you simulate this expression rather executing it:

		forBlock: [self assert: Processor activeProcess suspendedContext isNil]
		runUntil: [:ctx | ctx isDead or: [ctx selector = #defaultAction]])

Do you think this is a bug and should be fixed? We could do this by patching all assignors to suspendedContext in the 'changing suspended state' protocol on Process, maybe even as a small pattern like this:


		^ self doStep: [:ctx | ctx step]

		"Step until top context changes"

		^ self doStep: [:ctx | | ctxt |
			ctxt := ctx.
			[ctxt == ctx] whileTrue: [ctxt := ctxt step].

	doStep: aBlock
		| ctxt |
		ctxt := suspendedContext.
		suspendedContext := nil.
		^ suspendedContext := Processor activeProcess
			evaluate: [aBlock value: ctxt]
			onBehalfOf: self

Where #doStep: would handle the effective process and read, set to nil, and set again the suspendedContext of the receiver. Disclaimer: The above is pseudocode only so far.

Or isn't this worth the overhead and the invariant above has only to be valid for processes that are executed by the VM? :-)


Sent from Squeak Inbox Talk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211230/03409854/attachment.html>

More information about the Squeak-dev mailing list