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

Differences between 1.3 and version 1.4
Log of other versions for file ai12s/ai12-0098-1.txt

--- ai12s/ai12-0098-1.txt	2014/05/17 01:32:18	1.3
+++ ai12s/ai12-0098-1.txt	2014/07/15 03:26:24	1.4
@@ -1,5 +1,7 @@
-!standard 9.7.4(10-13)                              14-05-09    AI12-0098-1/00
+!standard 9.7.4(13)                                 14-07-14    AI12-0098-1/01
 !class ramification 14-05-09
+!status Corrigendum 2015 14-07-14
+!status ARG Approved 6-0-1  14-06-29
 !status work item 14-05-09
 !status received 14-04-10
 !priority Low
@@ -7,7 +9,7 @@
 !subject Problematic examples for ATC
 !summary
 
-** TBD.
+The examples in 9.7.4 assume appropriate abort completion points.
 
 !question
 
@@ -21,7 +23,7 @@
 only on core requirements.)
 
 In the first example, an input operation is not an abort completion point. Thus,
-the abortable part need done complete until some later time.
+the abortable part need not complete until some later time.
 
 In the second example, if Horribly_Complicated_Recursive_Function
 contains only calculations, it won't have any abort completion points and
@@ -33,58 +35,74 @@
 
 !response
 
-The examples accurately reflect the intent of the use of the feature. However,
+The examples accurately reflect the intended use of the feature. However,
 the questioner is correct that neither of these examples are required to work
 usefully in the absence of D.6.
 
-Therefore, something should be done. [The author does not know what, precisely.]
+Therefore, we add a note that the examples assume abort completion points
+within the abortable part.
 
-** TBD.
-
 !wording
+
+Add after 9.7.4(13):
 
-** TBD.
+Note that these examples presume that there are abort completion points within
+the execution of the abortable_part.
 
 !discussion
 
+9.8 says that a task only needs to be aborted at abort completion points.
+Of course, the implementation could support aborting it at other points,
+but that's not required of an Ada implementation (unless Annex D is
+supported, which is a separate issue).
+
+Thus, we add an explanation after the examples that we're assuming that
+the abortable_parts include abort completion points.
+
+For the second example, this is perfectly reasonable and possible -- the
+programmer must write their calculation so that it contains abort
+completion points, if they want to have a portable calculation.
+
+For the first example, this comment is more problematical. Clearly, the
+user cannot control whether a language-defined subprogram contains any
+abort completion points. They can put one or more into Process_Command,
+but the I/O routines cannot be assumed to be abortable.
+
 The question came up because the first example did not work on a Windows
 compiler. The initial response from an Ada language designer was that the
 compiler should be fixed. But Windows I/O operations are not interruptable
-in general; there are ways to make I/O operations interruptable but those
-have significant costs in complexity and overhead. Adding overhead to I/O
-in Windows programs just so ATC works are described in the examples would
-be silly and counterproductive.
-
-This is especially true as the formal description of the language does not
-require either of these examples to work. The second example is easily fixed
-(just assume that "delay 0.0;" is occassionally called in the long
-calculation). The first example is essentially unfixable - Get_Line is not
-an abort completion point and requiring it to be one would have unbearable
-costs on Windows (and likely other systems as well).
-
-The original questioner suggests that implementing D.6 for ATC on Windows
-might be difficult, but that is less interesting, as no Ada implementation
-is required to support Annex D. (The D.6 advice to use periodic polling to
-bound the cost of abort seems insane to the author; that requires the
-insertion of a relatively expensive operation into every piece of code
-- at a minimum into every long-running loop and call chain - in order to
-ensure the behavior of a rather rare operation.)
-
-The author sees two possible courses of action for the first example. One
-is to add some weasel words to the first example to the effect of whether
-this can be done depends on the underlying target system. However, I/O
-interruption is problematic on many target systems, so having an expection
-that this will work is bogus -- especially as the formal language of the
-standard certainly does not require it to work. So the other alternative
-(preferred by the author) is to delete this example altogether. Perhaps
-it should be replaced by something that would be required to work (I
-suggest interrupting a listing written with Put_Lines separated by
-delay statements).
-
-The second example needs some words stating that
-Horribly_Complicated_Recursive_Function contains additional abort completion
-points and that it can be assumed to stop only at those points (although
-it could stop earlier).
+in general (other threads can run, but the thread doing I/O has to wait for
+that I/O to completion); there are ways to make I/O operations interruptable
+but those have significant costs in complexity and overhead. Adding overhead
+to I/O in Windows programs just so ATC works are described in the examples
+would be silly and counterproductive.
+
+(Aside: The problem occurs on Windows if a 1-thread implementation of ATC
+is used. One could use a 2-thread model to implement ATC on Windows to
+side-step these issues, but that would encur costs to create a thread for
+each ATC, as well as ensuring that exceptions are delivered properly. It's
+probable that such an implementation would allow ATC to "work", but it
+might be too slow to use in practice.)
+
+We will not try to address this problem; if Get_Line doesn't include
+an abort completion point, the example probably won't work as intended.
+Hopefully, implementers will not be pressured into providing high-overhead
+I/O implementations just to make ATC examples like this one to work.
+
+!corrigendum 9.7.4(13)
+
+@dinsa
+@xcode<@b<select>
+   @b<delay> 5.0;
+   Put_Line("Calculation does not converge");
+@b<then abort>
+   -- This calculation should finish in 5.0 seconds;
+   --  if not, it is assumed to diverge.
+   Horribly_Complicated_Recursive_Function(X, Y);
+@b<end select>;>
+@dinst
+Note that these examples presume that there are abort completion points within
+the execution of the @fa<abortable_part>.
 
 !ASIS
 

Questions? Ask the ACAA Technical Agent