[squeak-dev] Solving multiple termination bugs - summary & proposal

Christoph Thiede christoph.thiede at student.hpi.uni-potsdam.de
Sun Apr 25 18:30:10 UTC 2021


Hi Jaromir,

I am extremely sorry for not giving any feedback on all your fixes and
proposals earlier. A few weeks ago, I was on holiday, then back at home, I
was greeted by a huge inbox with 100+ unread emails, and somehow I just lost
track of all your important updates ... Luckily, Nicolas has shown more
energy than me and has helped your contributions to find their way into the
Trunk! 🎉

Your summary in this post was extremely helpful for me to get an overview of
all the ongoing changes. I think I understood most of it, but here are some
open questions and to-dos from my point of view:

1. Regarding issue no. #5 in your list above ("Bug in Process>>#terminate |
Returning from unwind contexts" [1]): Do you consider this thread resolved
by now or is my answer to it still being expected? At the moment, this
snippet you mentioned fails to unwind completely:

x := nil.
[self error: 'x1'] ensure: [
    [self error: 'x2'] ensure: [
        [self error: 'x3'] ensure: [
            x:=3].
        x:=2].
    x:=1].

2. What is the current state of this thread [2]? If all issues are resolved
from your perspective, there is no need to discuss anything further -
otherwise, I guess it's your turn to answer again. :)

3. I noticed that Process >> #terminate contains multiple direct sends to
#runUntilErrorOrReturnFrom:. There are multiple real and potential problems
with this:

3.1 Consider the following snippet:

| p |
p := Processor activeProcess.
Transcript showln: p == Processor activeProcess.
[Transcript showln: p == Processor activeProcess] ensure: [
	Transcript showln: p == Processor activeProcess].
p

Debug it, then step into the first block, and abandon the debugger. We would
expect to see another "true" in the Transcript, but instead, we see a
"false". This is because #runUntilErrorOrReturnFrom: does not honor
process-faithful debugging. The protocol on Process, on the other hand, does
so. So probably we would want to wrap these sends into
#evaluate:onBehalfOf:.

3.2 As I think I mentioned somewhere else already, the result of
#runUntilErrorOrReturnFrom: *must* be checked to make sure that the
execution or the unwinding has not halted halfway. I don't see this in
Process >> #terminate either. This might be the cause of the bug I mentioned
in #1 of this post. Probably it's the best idea to discuss this in [1], too.
:-)

4. What's the current state of tests? Have you contributed tests for all the
issues you mentioned above? This would be awesome. :-)

Organizational notes: For sake of overview, I propose to keep this thread of
the current level of abstraction and discuss all the implementation details
in separate threads such as [1]. Ideally, we should also "close" all the
different threads about Process issues by adding another message to each of
them in order to help our future selves to keep an overview of their
solutions ...

Happy processing!

Best,
Christoph

[1]
http://forum.world.st/Bug-in-Process-gt-gt-terminate-Returning-from-unwind-contexts-td5127570.html
[2]
http://forum.world.st/Refactoring-terminate-to-get-rid-of-cannot-return-errors-etc-td5127732.html



-----
Carpe Squeak!
--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html


More information about the Squeak-dev mailing list