<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" style="word-wrap:break-word"> <div class="WordSection1"> Hi All, <o:p> </o:p> 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. <o:p> </o:p> 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. <o:p> </o:p> 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 :) <o:p> </o:p> Before boring you to death I'll list the bugs: <o:p> </o:p> 1. #isTerminated falsely reports almost any bottom context as terminated <o:p> </o:p> 2. an active process termination bug causes an image freeze <o:p> </o:p> 3. a nested unwind bug: ensure blocks may get skipped during unwind <o:p> </o:p> 4. a failure to complete nested unwind blocks halfway thru execution <o:p> </o:p> 5. a failure to correctly execute a non-local return or an error in an unwind block <o:p> </o:p> 6. inconsistent semantics of protected blocks unwind during active vs. suspended process termination <o:p> </o:p> 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: <o:p> </o:p> This approach looks inconsistent and indeed leads to inconsistencies, undesirable behavior and an instability mentioned above. <o:p> </o:p> 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. <o:p> </o:p> A commented code is enclosed. <o:p> </o:p> I know it's pretty difficult to get a feedback on an ancient code; I'll be all the more grateful for your inputs. <o:p> </o:p> Best regards, <o:p> </o:p> Jaromir <o:p> </o:p> <o:p> </o:p> 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. <o:p> </o:p> 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. <o:p> </o:p> ad 2) Explained in [1]. Concerns e.g. examples like [ [ Processor activeProcess terminate ] ensure: [ Processor activeProcess terminate ] ] fork. <o:p> </o:p> ad 3-4) Explained in detail in [2]. <o:p> </o:p> One example to illustrate the bug: <o:p> </o:p> | p | p := [ [ [ ] ensure: [ [ ] ensure: [ Processor activeProcess suspend. Transcript show: 'x1']. Transcript show: 'x2'] ] ensure: [ Transcript show: 'x3'] ] newProcess. p resume. Processor yield. p terminate <o:p> </o:p> ===> x1 <o:p> </o:p> The unwind procedure prints just x1 and skips not only x2 but x3 as well ! You'd like to see them all. <o:p> </o:p> 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. <o:p> </o:p> ad 6) I just prefer a unified approach... unless I somehow overlooked a reason for two different approaches (I hope not). <o:p> </o:p> <o:p> </o:p> [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 <o:p> </o:p> </div> </body> </html>