From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5a05d88755a62a0e X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Asynchronous Transfer of Control Date: 1996/10/29 Message-ID: #1/1 X-Deja-AN: 193178003 references: <32656457.1A76@csehp1.mdc.com> <326E3BD9.62CB@csehp1.mdc.com> <846525505.18309@dejanews.com> organization: New York University newsgroups: comp.lang.ada Date: 1996-10-29T00:00:00+00:00 List-Id: James Squire worries about me noting that abort completion points are still important if annex D is implemented, when Tuck said they are not. In fact these statements are not inconsistent, even though they appear to be. What Tuck was saying is that if you are worried about the immediacy of abort, then the issue of abort completion points is not important, since it is annex D that describes the latency of aborts. What I was saying is that if you are concerned with the exact set of events that can occur, in terms of reasoning formally about state, then abort completion points are important. What an abort completion point promises is that if a task is aborted, then it is NEVER the case that a statement after this point is executed, even if the latency guaranteed in annex D would permit such an execution sequence. It is quite possible to construct a test where this reasoning makes a difference to the invariants of the program state after the abort has taken place.