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

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

--- ai12s/ai12-0098-1.txt	2014/05/09 22:58:47	1.1
+++ ai12s/ai12-0098-1.txt	2014/05/13 02:32:33	1.2
@@ -1,7 +1,7 @@
 !standard 9.7.4(10-13)                              14-05-09    AI12-0098-1/00
-!class ramification 13-05-091
-!status work item 13-05-09
-!status received 13-04-10
+!class ramification 14-05-09
+!status work item 14-05-09
+!status received 14-04-10
 !priority Low
 !difficulty Medium
 !subject Problematic examples for ATC
@@ -25,7 +25,7 @@
 
 In the second example, if Horribly_Complicated_Recursive_Function
 contains only calculations, it won't have any abort completion points and
-therefore may not complete when the delay expires.  
+therefore may not complete when the delay expires.
 
 Unless the implementation is claiming Annex D support (and thus supporting
 D.6), neither of these examples need work as explained in the standard.
@@ -102,7 +102,8 @@
 !from Adam Beneschan 14-04-10
 !discussion
 
-RM 9.7.4 contains two examples demonstrating how asynchronous transfer of control can be used:
+RM 9.7.4 contains two examples demonstrating how asynchronous transfer of
+control can be used:
 
 ===============================================================================
 Example of a main command loop for a command interpreter:
@@ -131,28 +132,47 @@
       end select;
 ===============================================================================
 
-The problem is that neither of these examples is guaranteed to work as claimed.  When the entry call or delay is completed, the abortable part is aborted.  However, this doesn't mean the abortable part stops executing immediately.  
-
-In the first example, 9.8 doesn't list an input operation as an abort completion point; also, the discussion of task states in 9(10) implies that the task isn't considered to be "blocked" since it's not held up "as part of some task interaction".  This me
ans that the abortable part doesn't have to complete immediately.  Based on a discussion today on comp.lang.ada, it appears that on the Windows implementation of GNAT, the Get_Line does not terminate immediately when the abortable part is aborted. 
-
-In the second example, if Horribly_Complicated_Recursive_Function
-contains only calculations, it won't have any abort completion points and therefore may not complete when the delay expires.  
+The problem is that neither of these examples is guaranteed to work as claimed.
+When the entry call or delay is completed, the abortable part is aborted.
+However, this doesn't mean the abortable part stops executing immediately.
 
-(Note that on Windows, according to my understanding, it's not generally possible to force a thread to terminate or to jump out of the code sequence to call an exception handler, except by using API calls that should be used only in emergencies.  The targ
et thread itself has to cooperate by polling for interrupts and using different versions of API calls that perform interruptible I/O operations.  I may not have all the details right.)
+In the first example, 9.8 doesn't list an input operation as an abort completion
+point; also, the discussion of task states in 9(10) implies that the task isn't
+considered to be "blocked" since it's not held up "as part of some task
+interaction".  This means that the abortable part doesn't have to complete
+immediately.  Based on a discussion today on comp.lang.ada, it appears that on
+the Windows implementation of GNAT, the Get_Line does not terminate immediately
+when the abortable part is aborted.
+
+In the second example, if Horribly_Complicated_Recursive_Function contains only
+calculations, it won't have any abort completion points and therefore may not
+complete when the delay expires.
+
+(Note that on Windows, according to my understanding, it's not generally
+possible to force a thread to terminate or to jump out of the code sequence to
+call an exception handler, except by using API calls that should be used only in
+emergencies.  The target thread itself has to cooperate by polling for
+interrupts and using different versions of API calls that perform interruptible
+I/O operations.  I may not have all the details right.)
 
 Based on this, I think the RM needs to be modified:
 
-(1) The comment "this will be abandoned upon terminal interrupt"
-should be removed, since it's making an assertion that is not necessarily true;
+(1) The comment "this will be abandoned upon terminal interrupt" should be
+removed, since it's making an assertion that is not necessarily true;
 
-(2) there should be some clarifying text that the examples may not work as shown, except that the second example can be guaranteed to work if Horribly_Complicated_Recursive_Function contains abort completion points, such as "delay 0.0", at strategic times
.
+(2) there should be some clarifying text that the examples may not work as
+shown, except that the second example can be guaranteed to work if
+Horribly_Complicated_Recursive_Function contains abort completion points, such
+as "delay 0.0", at strategic times.
 
 ****************************************************************
 
 From: Tucker Taft
 Sent: Thursday, April 10, 2013  1:44 PM
 
-I am reluctant to change these examples. They establish intent for the appropriate use of ATC, and if GNAT doesn't support them on Windows, that should probably be addressed, rather than backpedaling on the intent.
+I am reluctant to change these examples. They establish intent for the
+appropriate use of ATC, and if GNAT doesn't support them on Windows, that should
+probably be addressed, rather than backpedaling on the intent.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent