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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rochester!cornell!uw-beaver!mit-eddie!husc6!cca!mirror!ishmael!ada-uts!stt From: stt@ada-uts Newsgroups: comp.lang.ada Subject: Re: a tasking question for you Message-ID: <57900037@ada-uts> Date: Tue, 14-Jul-87 13:45:00 EDT Article-I.D.: ada-uts.57900037 Posted: Tue Jul 14 13:45:00 1987 Date-Received: Sat, 18-Jul-87 06:59:03 EDT References: <13@<12317696882> Nf-ID: #R:<12317696882:-1300:ada-uts:57900037:000:1257 Nf-From: ada-uts!stt Jul 14 13:45:00 1987 List-Id: Although I agree it is not specific here, it would not be meaningful for a rendezvous to continue after the caller receives TASKING_ERROR and begins to process it. A rendezvous by definition occupies the full attentions of both tasks. To be clear, it should probably say that TASKING_ERROR is raised no sooner than the completion of the rendezvous, and no later than the abnormal completion of the aborted task. As far as 9.10:8 -- Imagine a variable which is a large record being updated by record assignment. If a task is aborted and becomes completed in the middle of the assignment, then the value of the variable may be unmeaningful, with the record only partially updated, and perhaps even a single component only partially updated. In this sense, the value is formally "undefined," which means that it is erroneous to use or rely on the value. Similar wording appears in 3.2.1:17/18, where it states that "The execution of a program is erroneous if it attempts to evaluate a scalar variable with an undefined value. Similarly, the execution of a program is erroneous if it attempts to apply a predefined operator to a variable that has a scalar subcomponent with an undefined value." S. Tucker Taft c/o Intermetrics, Inc. Cambridge, MA 02138