CVS difference for ai12s/ai12-0326-1.txt
--- ai12s/ai12-0326-1.txt 2019/04/06 02:20:57 1.1
+++ ai12s/ai12-0326-1.txt 2019/04/17 02:46:56 1.2
@@ -1,4 +1,4 @@
-!standard 5.5.3(17/5) 19-04-05 AI12-0326-1/01
+!standard 5.5.3(17/5) 19-04-15 AI12-0326-1/02
!class Amendment 19-04-05
!status work item 19-04-05
@@ -8,8 +8,8 @@
!subject Consequence for incorrect Allows_Exit
-Execution is erroneous if an Allows_Exit subprogram handles all exceptions,
-or calls the access-to-subprogram parameter from a parallel construct.
+It is a bounded error if an Allows_Exit subprogram handles an exception in a
+when-others handler but does not re-raise the exception.
@@ -37,89 +37,63 @@
Add after 5.5.3(21/5):
-If a subprogram S has a True Allows_Exit aspect and is used in an
-iterator_procedure call, execution is erroneous:
+If a subprogram S has a True Allows_Exit aspect and is used in an
+iterator_procedure_call, it is a bounded error if S handles an
+exception in a *when others* exception handler but does not re-raise
+the exception. The possible effects are:
+ * the propagation of Program_Error;
+ * the propagation of an exception raised by S;
+ * the termination of the loop_statement with the procedural_iterator as
+ its iteration_scheme as though the loop_statement completed normally
+ rather than by a transfer of control;
+ * the continued execution of the loop_statement even though some
+ iteration ended with a transfer of control.
+ AARM Reason: We want to permit implementations to use normal
+ exceptions to implement a transfer of control out of the
+ AARM Implementation Note: We allow subprogram S to invoke the
+ anonymous local procedure P from a parallel construct. This
+ implies that the implementation should not implicitly declare
+ variables global to the loop_statement to carry
+ information about the transfer of control that caused the
+ loop_statement to complete. Instead it needs to encode the
+ information in, for example, the Exception_Information that
+ accompanies an exception used to signal the transfer of control,
+ or in some sort of per-thread storage.
- * if S does not propagate any exception propagated from a call to any
- access-to-subprogram parameter of S, if the exception was handled by
- a "when others" exception handler.
- AARM Reason: We want the implementation of a procedural iterator to be able
- to use exceptions to implement exits and other control flow without having
- to worry about the Allows_Exit subprogram. We allow "eating" of specific
- exceptions so that the iterator itself can use those as it sees fit; any
- exception that the implementation would use should be implementation-defined
- and thus would never appear explicitly in portable code.
- * if a call is made to any access-to-subprogram parameter of S from within
- a parallel construct.
- AARM Reason: A parallel construct can cause exceptions to disappear as one
- transfer-of-control is "chosen arbitrarily" when threads are canceled
- (see 5.1). In addition, a parallel construct could cause data races with
- the control information needed to determine the target of a transfer of
- control. An implementation could avoid that by making all control information
- atomic, but we don't want to make implementations slower just to guard
- against an unlikely case.
-AARM Ramification: These cases can happen directly in S, or in any subprogram
-called by S.
-Another concern that was identified during (private) discussion on this topic
-was the use of parallel constructs in Allows_Exit routines. Procedural
-iterators by their nature cannot be safely executed in parallel (it's
-not possible to have a contract on the access parameter, so it could have
-natural data races; moreover, the usual uses of such routines include
-some sort of up-level access which necessarily would be a data race).
-Therefore, executing the subprogram (which is really the body of the loop) in
-parallel without appropriate precautions is a step backwards in the safety of
-As such, we do not want "hidden" parallel operations involved with the actual
-execution of the loop. (We note that such operations could cause an exit
-exception to be lost, as there is no guarantee of which exception is
-propagated from a parallel construct.)
-We're trying to ensure that a canonical implementation that looks like the
-following would be possible without complication from a
- Exit_Code : Integer range 1 .. 4;
- ... other stuff as needed ...
- procedure Loop_Body is
- if ... then
- Exit_Code := 3;
- raise System.Procedural_Iterator_Transfer;
- end if;
- My_Container.Iterate_Procedure (Loop_Body'Access);
- when System.Procedural_Iterator_Transfer =>
- case Exit_Code is
- when 3 => null; -- Exit.
- end case;
-For this to work, Iterate_Procedure must propagate
-System.Procedural_Iterator_Transfer, and must not cause a data race with
-Of course, an implementation can use any implementation technique that it
-wants; there's no requirement to use an implementation-defined exception.
+This AI attempts to define what we expect of a subprogram S that has the
+Allows_Exit aspect True, meaning that it does not rely on exception handling
+to do cleanup, but instead relies on finalization.
+We have chosen to make this a bounded error rather than erroneous because the
+semantics of this construct are defined by equivalence with a currently legal
+construct, where the subprogram S would be allowed to do essentially anything
+it wanted to. We are reluctant to introduce erroneousness when the expansion
+has well-defined semantics under the same circumstances.
+Another concern that was identified during (private) discussion on this topic
+was the use of parallel constructs in Allows_Exit routines. We have chosen to
+allow the implementor of an Allows_Exit subprogram to use a parallel
+construct, since the whole point of the procedural iterator might be to create
+a more sophisticated parallel iteration of some sort. But this implies the Ada
+implementation must not presume it can use variables that are global to the
+loop to carry information about the nature of the transfer of control. Instead,
+it needs to be encoded in the Exception_Information accompanying the "abort
+exception" being used to signal the transfer of control. Again, our view is
+that this is a new feature, and there is no reason to permit more
+implementation dependence than necessary. Therefore we clarify that a use of
+a parallel construct is permitted, and the implementation needs to handle that
Questions? Ask the ACAA Technical Agent