CVS difference for ais/ai-00237.txt

--- ais/ai-00237.txt	2001/10/09 00:47:09	1.11
+++ ais/ai-00237.txt	2002/10/29 20:24:57	1.12
@@ -56,7 +56,7 @@
 
 !discussion
 
-Although it is not clear from the the standard, it is not possible in general
+Although it is not clear from the standard, it is not possible in general
 for a task to finalize its own attributes. This is because a task that is never
 activated may have attributes that require finalization.
 
@@ -144,7 +144,7 @@
 later. While the object does not exist, the function Value may simply return
 Initial_Value, rather than implicitly creating the object.
 @dinst
-If the task terminates before the master of the instantiation of
+If a task terminates before the master of the instantiation of
 Task_Attributes is finalized, an implementation may finalize the object
 corresponding to the attribute of the task at this time (instead of when
 the master of the instantiation is finalized), and reclaim any other
@@ -2053,8 +2053,106 @@
   The current task is undefined in the finalization (it might be a terminated
   task).
 
-These points were added to the discussion, and the use oc Current_Task during
+These points were added to the discussion, and the use of Current_Task during
 the finalization of a task attribute was made into a bounded error.
+
+*************************************************************
+
+From: Erhard Ploedereder
+Sent: Sunday, October 20, 2002 12:29 PM
+
+I had an old action item to substantiate my objections
+(at WG9 level) to AI-237. Here goes...
+
+To provide quick context for this mail:
+The current RM demands finalization of task attributes and
+release of any associated storage upon termination of the
+task.
+AI-237 delays the mandated finalization of task attributes
+to the finalization of the master of their handle type, i.e., of
+the instantiator of the Task_Attributes package. It gives
+an implementation permission to finalize earlier upon
+termination of a task with such an attribute.
+
+My objections to AI-237 are:
+
+1. In all likelihood, 99,9% of all such instantiations are
+at global level, so that the new rule is tantamount to saying
+that task attributes are (for all practical purposes) never
+finalized and associated storage is never released.
+
+2. To make the undesirable behavior the rule and the desirable
+behavior the implementation permission seems wrong to me.
+
+I agree that there might be implementation difficulties with the
+RM rule. And so, gnashing my teeth, I would be willing to
+agree to an implementation permission that delays the
+finalization, while the current RM rule stays in effect.
+(The expanded rule on Current_Task is o.k. in any case.)
+
+So (contrary to what I muttered at the Oct. meeting), I am
+calling for reconsideration of the issue by the ARG.
+
+Erhard
+
+PS: a couple of editorials on the current AI:
+first line of !discussion: "the the" -> "the"
+On the last para of !corrigendum C.7.2(28):
+    "If the task" -> "If a task"
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Sunday, October 20, 2002 12:33 PM
+
+I support this position
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, October 24, 2002  3:29 PM
+
+No, the current RM rule is wrong. It not only requires finalization earlier
+than the replacement, but in the case of a nested instantiation of Task
+Attributes, it might actually require finalization too late.
+
+It cannot be the case that the instantiation's master is left before the
+finalization occurs, because if it did, the finalization could reference
+objects (and even types) that no longer exist. This is completely missing
+from the RM, and a new rule needs to be added to handle that. That's what
+the last problem of the AI is about.
+
+Now, if you just add that rule to the original one, then you have two rules
+that specify where the finalization occurs, and they specify different
+places. That won't work.
+
+Additionally, there is also the problem with the race condition implicit in
+the current rule. So, the best solution was felt to be to get rid of the
+current rule, replacing it by one that specifies that finalization occurs
+where you would expect it to, and have a permission to allow finalization
+earlier.
+
+I understand your concern about the "wrong message" being given here, but I
+think you need to provide an alternative solution to the questions of the
+AI. Simply saying that the RM is OK (when it clearly isn't) and asking for
+reconsideration isn't very helpful.
+
+In any case, I have a hard time understanding what's the big deal. I've
+never had the slightest shred of customer interest in task attributes. We
+implement it only because its in the standard, and for that purpose the
+simplest implementation it best. The existing RM rule makes the
+implementation very complex for a feature that none of our customers want --
+it doesn't even pay to support it in that case.
+
+*************************************************************
+
+From: Robert A. Duff
+Sent: Thursday, October 24, 2002  4:10 PM
+
+I agree with Randy's technical points.  However, having just written a
+rant about the "interfaces" AI, I would like to point out that this Task
+Attribute AI, like most other AI's, will have near-zero effect on
+whether people choose Ada!
 
 *************************************************************