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 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!elma.epfl.ch!madmats From: madmats@elma.epfl.ch (Mats Weber) Newsgroups: comp.lang.ada Subject: Two Questions on Tasking Message-ID: <890403120542.20401f23@elcc.epfl.ch> Date: 3 Apr 89 11:05:42 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet List-Id: Bob Hathaway (rjh@purdue.edu) writes : >>This is because the execution of the task is independent of its creator. > According to section 9.4.1: "Each task depends on at least one master.". True, but the dependence on a master is for task termination. What I meant by "the execution of the task is independent of its creator" was that the task and its creator are two different threads of execution. >>If the exception were propagated to the task's creator, the exception >>handler in the creator could get exceptions from all tasks he has created. >>For example, if task A creates A.B, A.C and A.D and A.B raises Exception_B >>and A.C raises exception Exception_C, how would the handler in A deal with >>them ? >>The Ada rules on exceptions state that only one exception may be active in >>any thread of execution. >According to section 9.3.3, if any child task does not have a handler for >a raised exception, the exception TASKING_ERROR is propagated to the master >upon conclusion of the activation of all sibling tasks and is propagated >to the master only once for any number of concluded child tasks. What is >being asserted above? TASKING_ERROR is propagated to the master if an exception is raised during the activation (that is, the elaboration of the declarative part) of any child task, not otherwise. - Handlers in the child task do not apply to exceptions raised in its declarative part, just like in other blocks. - If an exception is raised in the child task after completion of its activation (that is, after the reserved word begin of the child task), then this exception is not propagated outside the child task even if the child task does not handle it (the exception gets lost, unnoticed, and the child task becomes completed). - What is being asserted above is what Scott Simpson (trwarcadia!simpson@oberon.usc.edu) says more clearly in his message, i.e. that if the language design would have incorporated exception propagation from already activated children tasks to their direct master, there would be asynchronous communication between the tasks. Moreover, if a given master has two or more child tasks, then several exceptions might be raised simultaneously in the master's thread of execution. - The master waits for the completion of the activation of all its children before he (the master) begins executing its own sequence of statements. This waiting makes it possible for Tasking_Error to be raised at a well defined point in the master (just before its first statement). Mats Weber Swiss Federal Institute of Technology EPFL DI LITh 1015 Lausanne Switzerland e-mail : madmats@elma.epfl.ch