CVS difference for ais/ai-00318.txt

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

--- ais/ai-00318.txt	2003/06/18 00:12:24	1.3
+++ ais/ai-00318.txt	2003/10/29 22:54:12	1.4
@@ -1737,3 +1737,89 @@
+From: Stephen W Baird
+Sent: Tuesday, October 14, 2003,  3:51 PM
+This is a discussion of the interaction between AI-318 and the
+IBM-Rational  Apex Ada compiler's implementation of finalization, as per
+my homework assignment from the Sydney ARG meeting.
+The Apex compiler manages pending finalization requirements (i.e.
+finalization of controlled and protected objects, not tasks) at the
+granularity of
+top-level (i.e. non-component) objects. The finalization code generated
+for the enclosing "construct or entity" (7.6.1(2)) of a given top-level
+object relies on the invariant that either all or none of the
+subcomponents of the object require finalization.
+This means, for example, that if an exception occurs while initializing an
+object, then the initialization code (which knows how far it has
+progressed) must handle the exception, finalize any components which were
+successfully initialized, and then (typically) reraise the exception. If
+an object cannot make it to the state where all of its subcomponents need
+to be finalized, then it must revert to the state where none require
+finalization before execution of the finalization code for the enclosing
+"construct or entity".
+This has proven to be a reasonable implementation model, but AI-318 might
+be difficult to implement using this approach. Consider the case of a
+return object which contains several controlled subcomponents. Suppose
+that some, but not all, of these subcomponents have been successfully
+initialized when an exception is raised. The code (in the callee) which
+knows how far initialization has progressed would have to handle the
+exception, perform any necessary finalization, and then (typically)
+reraise the exception.
+Unfortunately, the AI (as currently written) disallows this approach:
+    "The return object would not be finalized prior to leaving the
+function. The caller would be responsible for its finalization".
+This problem could be resolved by having this provision of the AI apply
+only in the case of a "normal completion" (7.6.1(2)) of the function, with
+the callee responsible for finalization otherwise (or perhaps just by
+adding an implementation permission allowing the callee to perform
+finalization in this case).
+It cannot always be known whether a function is going to return normally
+until after any other finalization of objects declared by the function has
+completed. Thus, the return object might have to be the last object to be
+finalized. This could be accomplished either by requiring that it be the
+first object with nontrivial finalization to be declared or by inventing a
+special dynamic-semantics rule to handle this case (perhaps only an
+implementation permission).
+The Apex Ada compiler implements abortion (including ATC) by means of a
+distinguished anonymous "exception". Thus, abortion while the callee is
+executing introduces essentially the same problem for the caller as if the
+callee propagated an exception. The distinction between normal and
+abnormal completion proposed above would also help in resolving this
+From: Robert A Duff
+Sent: Wednesday, October 15, 2003, 11:53 AM
+> This problem could be resolved by having this provision of the AI apply
+> only in the case of a "normal completion" (7.6.1(2)) of the function, with
+> the callee responsible for finalization otherwise ...
+That makes sense to me.  How can it make sense to let the caller do the
+finalization of the result when the function is not returning a result,
+but is propagating an exception instead?
+Also, Steve is talking about the case where the returned object is "half
+baked".  But what if it hasn't been initialized at all?  I believe there
+would be trouble in that case, too.
+>...(or perhaps just by
+> adding an implementation permission allowing the callee to perform
+> finalization in this case).
+I'm not a big fan of implementation permissions, but I would have no
+objection in this case.

Questions? Ask the ACAA Technical Agent