[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:
(Process
forBlock: [self assert: Processor activeProcess suspendedContext isNil]
runUntil: [:ctx | ctx isDead or: [ctx selector = #defaultAction]])
resume.
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:
step
^ self doStep: [:ctx | ctx step]
stepToCallee
"Step until top context changes"
^ self doStep: [:ctx | | ctxt |
ctxt := ctx.
[ctxt == ctx] whileTrue: [ctxt := ctxt step].
ctxt]
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? :-)
Best,
Christoph
---
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
|