CVS difference for ai12s/ai12-0326-1.txt

Differences between 1.1 and version 1.2
Log of other versions for file 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
 !standard 5.5.3(21/5)
 !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):
-Erroneous Execution
+Bounded Error
-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
+      loop_statement.
+      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
-parallel operations.
-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 
-    declare
-        Exit_Code : Integer range 1 .. 4;
-        ... other stuff as needed ...
-        procedure Loop_Body is
-        begin
-           ...;
-           if ... then
-              Exit_Code := 3;
-              raise System.Procedural_Iterator_Transfer;
-           end if;
-           ...;
-        end;
-     begin
-        My_Container.Iterate_Procedure (Loop_Body'Access);
-     exception
-        when System.Procedural_Iterator_Transfer =>
-           case Exit_Code is
-              ...
-              when 3 => null; -- Exit.
-              ...
-           end case;
-     end;
-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