CVS difference for ais/ai-10266.txt

Differences between 1.2 and version 1.3
Log of other versions for file ais/ai-10266.txt

--- ais/ai-10266.txt	2002/06/12 00:36:46	1.2
+++ ais/ai-10266.txt	2002/06/14 23:48:56	1.3
@@ -1328,3 +1328,134 @@
 
 ****************************************************************
 
+From: Ted Baker
+Sent: Wednesday, June 12, 2002  9:06 AM
+
+| I was assuming the termination handler is called by the terminating
+| task.  Thus, "is called when any subtask terminates" ought to be "before
+| the task terminates."  Otherwise, we get into the can of worms Ted
+| describes.  -- Bob
+
+It would indeed simplify things if the handler is required to be
+called by the terminating task, after the last normal user-defined
+finalization, and after the 'Terminated attributed becomes true.
+The semantics, including restrictions on the actions of
+the handler, could then be similar to other finalizers.
+
+I guess this handler should be called immediately after the point
+where the finalizers of any user-defined task attributes takes place:
+
+| 17   When a task terminates, the implementation shall finalize all attributes
+| of the task, and reclaim any other storage associated with the attributes.
+
+****************************************************************
+
+From: Ted Baker
+Sent: Wednesday, June 12, 2002  9:27 AM
+
+I should add to Randy's question and my previous comments, the
+big question:
+
+What does this proposal provide that is not already provided
+by the finalizer of a user-defined task attribute of a controlled type?
+
+****************************************************************
+
+From: Tullio Vardanega
+Sent: Wednesday, June 12, 2002  10:02 AM
+
+Ted Baker wrote:
+
+> I should add to Randy's question and my previous comments, the
+> big question:
+>
+> What does this proposal provide that is not already provided
+> by the finalizer of a user-defined task attribute of a controlled type?
+
+
+That finalizing a contained entity (or an attribute)
+to handle the termination of the containing scope
+(perhaps only for notification) is an inversion of
+abstraction.
+
+That there may be contexts where object finalisation
+may be as unwelcome as exception handling, while
+an explicit access-to-protected procedure that
+executes on task termination may be acceptable
+and useful.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, June 12, 2002   1:53 PM
+
+> That finalizing a contained entity (or an attribute)
+> to handle the termination of the containing scope
+> (perhaps only for notification) is an inversion of
+> abstraction.
+
+No, it means that *your* view of Ada is inverted. Tasking is built on top of
+(and is less important than) Finalization, not the other way around.
+Sometimes you need to think outside of the box...
+
+> That there may be contexts where object finalisation
+> may be as unwelcome as exception handling, while
+> an explicit access-to-protected procedure that
+> executes on task termination may be acceptable
+> and useful.
+
+Let me get this straight. You postulate that there are contexts in which the
+compiler needs to provide finalization (by calling an access-to-procedure),
+because it is too unsafe to use the finalization provided by the compiler
+(object finalization)?
+
+In my opinion, if you cut out exception handling and finalization, the
+result is no longer Ada. If you want to code in threaded AdaTran, go ahead,
+but I don't see any obligation to complicate the Ada language and runtimes
+just to make life easier for you. Particularly when the proposed feature
+only compounds my technical support problems in this area, offering only the
+suggestion of help without any help whatsover. Let the threaded AdaTran
+vendor provide whatever features are necessary.
+
+****************************************************************
+
+From: Alan Burns
+Sent: Thursday, June 13, 2002   7:13 AM
+
+I thought it might be useful to clarify some (mainly
+non-technical) issues surrounding Task Termination,
+AI266, and the Real-Time Workshop (IRTAW).
+
+The request for this task termination feature did not
+come from IRTAW. We (IRTAW) were asked to comment
+on the AI. I believe the requirement for this type of feature
+came from a workshop on exception handling.
+
+For the full language we felt that the AI added little, the
+use of exception handling and finalization (our arms and legs
+as Randy puts it) gives all the expressive power required. What
+was attractive about the AI was the ability to assign a handler
+to a set of tasks (indeed the whole program if desired) rather
+than to each task in turn. But this was not really a real-time issue.
+
+The other issue about the AI is that it proposes an alternative
+means of getting certain functionality which may be of interest
+if exceptions and/or controlled types were not being used.
+In this situation we felt a simpler feature would
+be sufficient - hence the alternative proposal.
+However, we understood that the ARG required that any such feature
+should apply to the whole language rather than a language subset.
+
+In Ravenscar there is an implicit assumption that tasks do not terminate.
+One implementation has allowed the user to associate code with
+termination as a fault recognition feature - but using a facility
+outside of Ada. Our proposal was a means of bringing this, in a
+simple way, within the language. Remember Ravenscar does not itself
+prohibit exceptions nor controlled types - but some users do
+require these extra restrictions.
+
+In summary, for the full language does AI 266 add sufficient new
+functionality? and for restricted domains is it too complicated?
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent