CVS difference for ai05s/ai05-0045-1.txt

--- ai05s/ai05-0045-1.txt	2007/04/06 03:10:41	1.2
+++ ai05s/ai05-0045-1.txt	2007/07/26 02:57:26	1.3
@@ -1,6 +1,4 @@
-!standard 9.2(6)                                                07-04-04    AI05-0045-1/01
-!standard 9.2(9)
-!standard 9.3(5)
+!standard 9.2(6)                                                07-06-13    AI05-0045-1/02
 !class binding interpretation 07-04-04
 !status work item 07-04-04
 !status received 07-04-02
@@ -10,8 +8,7 @@
 !subject Termination of unactivated tasks
 !summary
 
-Tasks that are created but never activated become terminated when the master that they
-depend on begins to wait for tasks.
+Tasks that are created but never activated become terminated when their master is finalized.
 
 !question
 
@@ -36,47 +33,46 @@
 
 !wording
 
-Delete 9.2(6).
+Replace 9.2(6) by:
 
-Add a new note after 9.2(9):
+If a master includes (directly or indirectly) the creation of a task, and it begins
+finalization prior to either initiating the activation of the new task or returning
+the task to a caller as part or coextension of a return object, the new task is never
+activated and becomes terminated.
 
-It is possible for newly created tasks to never be activated if the point that
-would initiate the activations is never reached (for example, due to the raising
-of an exception). In this case, the tasks are never activated.
-
-AARM Note: This also can happen because of an abort, or because of a transfer of
-control out of an extended_return_statement.
-
-Modify paragraph 9.3(5):
-
-A task is said to be completed when the execution of its corresponding task_body
-is completed. A task is said to be terminated when any finalization of the
-task_body has been performed (see 7.6.1). The first step of finalizing a master
-(including a task_body) is to wait for the termination of any tasks dependent on
-the master. {At the start of this step, any tasks dependent on that master that
-have not been activated become terminated and are never activated.} The task
-executing the master is blocked until all the dependents have terminated. Any
-remaining finalization is then performed and the master is left.
+AARM Note: A master could indirectly include the creation of a task if the task is
+returned to it from a function call. This rule covers such tasks that aren't activated.
 
+A created task might not be activated because of an exception being raised, because
+of an abort, or because of a transfer of control out of an extended_return_statement.
+
 !discussion
 
-What is important here is what happens if we need to wait for tasks that aren't
-activated. We don't really care why the tasks were never activated. Thus, the original
-wording of 9.2(6) says too much. It also has a race condition, in that if the 
-task is aborted when it reaches the activation point but before the tasks actually
-are activated, this rule doesn't seem to apply.
+What is important here is what happens if the master of unactivated tasks is finalized
+(as then we would need to wait for them). We don't care why the tasks were never
+activated. Thus, the original wording of 9.2(6) says too much. It also has a race
+condition, in that if the task is aborted when it reaches the activation point but
+before the tasks actually are activated, this rule doesn't seem to apply.
 
 The wording also is not clear about precisely when the tasks become terminated. The tasks
 being terminated on creation would meet the requirements of this rule. Thus, the value
 of T'Terminated is not well-defined for such tasks. That seems bad.
+
+Because of all of these reasons, we've rewritten the rule in terms of finalization
+rather than "reaching the point of activation".
 
-Because of all of these reasons, we've chosen a much simpler rule that has the same effect.
-Because the new rule is specifically about task termination and depends on the definitions
-in that section, it is best put into 9.3. and we've removed the old rule from 9.2 and
-replaced it with a user note.
 
---!corrigendum 9.2(6/2)
+!corrigendum 9.2(6/2)
 
+@drepl
+Should the task that created the new tasks never reach the point where it would
+initiate the activations (due to an abort or the raising of an exception), the
+newly created tasks become terminated and are never activated. 
+@dby
+If a master includes (directly or indirectly) the creation of a task, and it begins
+finalization prior to either initiating the activation of the new task or returning
+the task to a caller as part or coextension of a return object, the new task is never
+activated and becomes terminated.
 
 !ACATS test