[squeak-dev] Abandoning in debugger and ensure: blocks

Jaromir Matas mail at jaromir.net
Tue Jun 21 17:30:10 UTC 2022


Hi Christoph,

> To restore the old termination semantics in Squeak 6.0, you can send #terminateAggressively instead of #terminate.

Well, that's not entirely true: If you terminate the process p in this slightly modified example in 5.3

p := [
[x := 1]
ensure:
[x := 2.
Semaphore new wait.
x := 3]
] fork

you get x = 3
which means 5.3 #terminate unwinds some half-way through unwind blocks; see Andreas's comment:
                                                "If we are terminating a process halfways through an unwind, try
                                                to complete that unwind block first."

If you terminate the same process p above using #terminateAggressively in 6.0 you get x = 2.

> the semantics of Debugger's Abandon do not have changed

It seems like this slight deviation won't show in the debugger because luckily the debugger places one #ensure context when opening (openOn:context:label:contents:fullView:) and that 'breaks' the search for a half-way through unwind context in 5.3 neutralizing the difference in the semantics; however, should terminateAggressively be used other than in the debugger one should be aware of the difference.

I wonder: could this have something to do with the bug in https://github.com/squeak-smalltalk/squeak-object-memory/issues/44 ?? Probably not; wild guess :)

Best,


--

Jaromír Matas

mail at jaromir.net

From: Thiede, Christoph<mailto:Christoph.Thiede at student.hpi.uni-potsdam.de>
Sent: Tuesday, June 21, 2022 11:33
To: The general-purpose Squeak developers list<mailto:squeak-dev at lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Abandoning in debugger and ensure: blocks


Hi Tony,



no, the semantics of Debugger's Abandon do not have changed: When you press Abandon, all ensure: contexts will be run that are not yet active.



Example 1:


[x := 1.
self halt]
ensure:
[x := 2].


If you abandon the debugger, x will be set to 2.



Example 2:


[x := 1.
^1]
ensure:
[x := 2.
self halt.
x := 3].

If you abandon the debugger, x will be set to 2 (but not to 3 - so the active ensure: context will *not* be continued).

The only thing that has changed is the semantics of Process >> #terminate:

Example 3:

[[x := 1.
Processor terminateActive]
ensure:
[x := 2]] fork.

x will be set to 2.

Example 4:

[[:exit | [x := 1.
exit value]
ensure:
[x := 2.
Processor terminateActive.
x := 3]] valueWithExit] fork.

In Squeak 5.3 and earlier, x will be set to 2 only.
In Squeak 6.0 and newer, x will be set to 3, so the active ensure context will indeed be completed during termination.

To restore the old termination semantics in Squeak 6.0, you can send #terminateAggressively instead of #terminate. This is what Debugger's Abandon uses under the hood.

You can find more examples in DebuggerTests no. 19 - 24. For the termination semantics, see also the tests in the AbstractProcessTest hierarchy.

HTH,
Christoph


Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Tony Garnock-Jones <tonyg at leastfixedpoint.com>
Gesendet: Dienstag, 21. Juni 2022 10:50 Uhr
An: The general-purpose Squeak developers list
Betreff: [squeak-dev] Abandoning in debugger and ensure: blocks

Hi all,

Is it true that with recent changes to termination, if I "Abandon" a
process in the debugger, that process's `ensure:` blocks will NOT run?

That's a change from before, right?

Or am I mistaken?

If that's genuinely the case, is there some mechanism I should be using
to `reallyEnsure:` that something happens as part of process termination?

Thanks!

Tony

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220621/44abe9cd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4F308467B1EA48319883B85BD4190795.png
Type: image/png
Size: 144 bytes
Desc: 4F308467B1EA48319883B85BD4190795.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220621/44abe9cd/attachment.png>


More information about the Squeak-dev mailing list