[squeak-dev] Refactoring #terminate to get rid of 'cannot return' errors etc.

Jaromir Matas m at jaromir.net
Tue Mar 16 23:05:24 UTC 2021


Hi Christoph,

Many thanks for your inspiring questions! I really appreciate that.

My main motivations (apart from curiosity and learning):

1. Avoid 'cannot return' errors - by no means I want "resumable" terminated
processes ;) I just thought resuming them should be harmless; it could save
checking whether a process is terminated to avoid errors. Real life
examples? I'm thinking parallel computing where one process can terminate
while another one running in parallel might still want to resume it assuming
or hoping it is only suspended (without an explicit check that would raise
an exception). Just a thought...

Resuming a terminated process in this scenario wouldn't really "resume" it
but only suspend it again to avoid the 'cannot return' error.

2. Readability of the code (newProcess's logic isn't easy to decode)

3. Easy way to spot a terminated process while debugging :)
(suspendedContext = Process>>#terminated)

> Clean up logic for testing termination. [...] Because there could still be
> processes not using the new #terminated marker and thus requiring us to
> keep the old mechanisms. 

Yes, you're right some processes might still be created the alternative way
("manually") as long as the alternative way is available but that doesn't
mean extending the current isTerminated logic - only keeping it the same. I
don't even think it can be simplified any further beyond these conditions:
	a) process is defunct / dead, or
	b) process is parked in #terminated, or
	c) process is at its last instruction

But yes, my proposal doesn't decrease complexity, only - I hope - increases
readability. I wouldn't dare to introduce anything in addition to the
existing that would increase complexity. I'm convinced the core code must be
kept at minimum complexity and maximum readability :)

> I don't think we should consider these variables of a stack frame as
> mutable fields. [...] Wouldn't it be possible to replace the context
> instance instead?

That's an interesting idea... Thanks!
Widowed, divorced or single should be ok so only married ones can have a
problem :) I can't answer this one but at least in my image it works. 
However, replacing:
		ctxt setSender: nil receiver: self method: (Process>>#terminated)
arguments: {}.

with:
		ctxt := Context sender: nil receiver: self method: (Process>>#terminated)
arguments: {}

doesn't update the stack frame because nothing happens, however the
#setSender apparently must update the stack frame because it seems to work;
I guess it's because it manipulates an existing spouse (context) instead of
replacing her with a brand new. Once married the stack frames cannot replace
their spouse contexts after all ;) However I'm not an expert in these
matters. I'll explore...

Again, thanks for your feedback,
best regards,




-----
^[^ Jaromir
--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html


More information about the Squeak-dev mailing list