[Cuis-dev] Unwind mechanism during termination is broken and inconsistent

[Hernan Wilkinson]

Hi Jaromir,
 thank you for sharing this with us! It looks very interesting.
 As you can imagine a change of this magnitude and impact has to be
analyzed in detail and tested rigorously, and that will take time. (Sadly
Juan and me are really busy at this time so it will even take more time :-)
)
 It would help us deeply if there are tests that reproduce the errors, do
you have them? If not, could you write them? I know it is a difficult
problem to test but if we could have automated tests for this it would help
a lot.
 Also, it would help to know how you tested it. For example, have you tried
in stress conditions? for example with an app that uses many processes (ie.
seaside or any web framework). Please, do not take this question as
disrespectful, but again, it is a change with a big impact and we need to
be sure it will keep the current behavior (but the bugs of course) and it
will not introduce new bugs.
 I'm also wondering if there could be systems that are implemented as these
bugs you mention were "features" ...

 Thanks!
 Hernan.


On Sat, Apr 10, 2021 at 4:20 PM Jaromir Matas via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> Hi All,
>
>
>
> I'd like to present to you a rewrite of #terminate and #isTerminated that
> fixes a few bugs and inconsistencies in process termination. I hoped it
> might interest you.
>
>
>
> I'm a Smalltalk enthusiast with education background in math/CS. I've been
> experimenting with processes in Squeak lately and discovered a few bugs (or
> at least inconsistencies) in process termination and would like to offer
> and discuss a solution for Cuis.
>
>
>
> The bugs are not unique to Cuis; Squeak/Pharo inherited them too and to a
> degree even Visual Works and VA are affected. The proposal presented here
> doesn't copy any VW or VA solution but rather implements a different
> approach :)
>
>
>
> Before boring you to death I'll list the bugs:
>
>
>
> 1. #isTerminated falsely reports almost any bottom context as terminated
>
>
>
> 2. an active process termination bug causes an image freeze
>
>
>
> 3. a *nested* unwind bug: ensure blocks may get skipped during unwind
>
>
>
> 4. a failure to complete *nested* unwind blocks halfway thru execution
>
>
>
> 5. a failure to correctly execute a non-local return or an error in an
> unwind block
>
>
>
> 6. inconsistent semantics of protected blocks unwind during active vs.
> suspended process termination
>
>
>
> The current implementation of #terminate uses three different approaches
> to terminate a process:
>
> - the active process is terminated via a 'standard' unwind algorithm used
> in context #unwindTo: or #resume:,
>
> - a suspended process termination attempts completing unwind blocks
> halfway through their execution first using #runUntilErrorOrReturnFrom:
>
> - and after that the termination continues unwinding the remaining unwind
> blocks using the simulation algorithm of #popTo:
>
>
>
> This approach *looks* inconsistent and indeed leads to inconsistencies,
> undesirable behavior and an instability mentioned above.
>
>
>
> The Idea: In my view the easiest and most consistent solution is to simply
> extend the existing mechanism for completing halfway-through unwind blocks
> and let it deal with *all* unwind blocks. To make this approach
> applicable to terminating the active process, we suspend it first and then
> terminate it as a suspended process.
>
>
>
> A commented code is enclosed.
>
>
>
> I know it's pretty difficult to get a feedback on an ancient code; I'll be
> all the more grateful for your inputs.
>
>
>
> Best regards,
>
>
>
> Jaromir
>
>
>
>
>
> PS:
>
> Note the change in newProcess - `Processor activeProcess terminate` is
> replaced by `Processor activeProcess suspend` because there's no need for
> `terminate` at the bottom context ("terminate = unwind + suspend") and
> because it would lead to an infinite loop combined with my proposed changes
> to #terminate.
>
>
>
> PPS:
>
> More on the bugs:
>
> ad 1) The #isTerminated condition `suspendedContext pc > suspendedContext
> startpc` is always met after executing the first instruction of the bottom
> context – generally not a sign of a terminated process.
>
>
>
> ad 2) Explained in [1]. Concerns e.g. examples like
>
>               [ [ Processor activeProcess terminate ] ensure: [ Processor
> activeProcess terminate ] ] fork.
>
>
>
> ad 3-4) Explained in detail in [2].
>
>
>
> One example to illustrate the bug:
>
>
>
> | p |
>
> p := [
>
>               [
>
>                            [ ] ensure: [
>
>                                          [ ] ensure: [
>
>                                                        Processor
> activeProcess suspend.
>
>                                                        Transcript show:
> 'x1'].
>
>                                          Transcript show: 'x2']
>
>               ] ensure: [
>
>                            Transcript show: 'x3']
>
> ] newProcess.
>
> p resume.
>
> Processor yield.
>
> p terminate
>
>
>
> ===> x1
>
>
>
> The unwind procedure prints just x1 and skips not only x2 but x3 as well !
> You'd like to see them all.
>
>
>
> ad 5) This happens in cases like (better save your image before trying
> this):
>
>               [self error: 'e1'] ensure: [^2]        "discovered by
> Christoph Thiede"
>
> and
>
>               [self error: 'e1'] ensure: [self error: 'e2']
>
> These are generally the types of situations causing the Unwind errors. The
> root cause is that the unwinding is done via simulation (#popTo) rather
> than 'directly'; the problem is during the simulated execution of unwind
> blocks a non-local return forwards the execution into a wrong stack -
> resulting in the Unwind errors.
>
>
>
> ad 6) I just prefer a unified approach... unless I somehow overlooked a
> reason for two different approaches (I hope not).
>
>
>
>
>
> [1]
> http://forum.world.st/A-bug-in-active-process-termination-crashing-image-td5128186.html
>
> [2]
> http://forum.world.st/Another-bug-in-Process-gt-gt-terminate-in-unwinding-contexts-td5128171.html#a5128178
>
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>


-- 
<https://10pines.com/>Hernán WilkinsonSoftware Developer, Teacher & Coach

Alem 896, Floor 6, Buenos Aires, Argentina

+54 11 6091 3125

@HernanWilkinson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20210410/05fbbfb5/attachment-0001.htm>