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

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

--- ai12s/ai12-0031-1.txt	2013/07/18 05:05:30	1.4
+++ ai12s/ai12-0031-1.txt	2013/12/18 00:53:46	1.5
@@ -1,4 +1,4 @@
-!standard E.2.3(19/3)                              12-11-17    AI12-0031-1/02
+!standard E.2.3(19/3)                              13-11-15    AI12-0031-1/03
 !class binding interpretation 12-11-17
 !status work item 12-06-06
 !status received 12-05-17
@@ -7,216 +7,80 @@
 !subject All_Calls_Remote and indirect calls
 !summary
 
-All_Calls_Remote only applies to direct calls.
+All_Calls_Remote applies to direct non-local calls, indirect, and dispatching
+remote calls.
 
 !question
 
 Does E.2.3(19/3) apply to indirect calls (that is those through
-access-to-subprogram values)? (No.)
+remote access-to-subprogram values)? (Yes.)
 
-There are unnecessary complications if the clause applies to calls through
-access-to-subprogram objects.
+Does E.2.3(19/3) apply to dispatching calls (that is those through
+remote access-to-class-wide types)? (Yes.)
 
-For example, if the program calls through a remote-access-to-subprogram
-object, the access object will probably contain a partition_ID, and it
-makes sense for the caller to check to see if the partition_ID refers to
-the current partition and make a local call if so. But if the rules
-require that it be a PCS call if the subprogram is in an
-All_Calls_Remote package, the code would have to somehow determine
-whether the subprogram address were in such a package.
-
-Similarly, in the case of a normal access-to-subprogram object: the
-access object is probably just the address of a subroutine, and it would
-be the same subroutine that would be called for a direct call, which,
-for a remote subprogram in an All_Calls_Remote package, would be the
-address of a subroutine that uses the PCS to call the target routine. If
-such an access-to-subprogram object were then passed to a routine in a
-child package of the RCI unit, and the second sentence of E.2.3(19)
-applied to indirect calls, the child package code would have to somehow
-check the address in the access-to-subprogram object to see if it refers
-to a remote subprogram in the parent unit, so that it could make a local
-call instead of going through the PCS.
-
 !recommendation
-
-The wording is changed so that the All_Calls_Remote aspect only applies
-to direct calls to an RCI unit package. Indirect calls are always
-considered as being outside of the declarative region and it is up to
-the implementation to decide whether such calls to the same partition
-are routed through the PCS.
 
-!wording
+The wording is changed so that the All_Calls_Remote aspect applies to all 
+indirect or dispatching remote subprogram calls to the RCI unit as well as to 
+direct calls from outside the declarative region of the RCI unit. Indirect and
+dispatching calls are always considered as being from outside of the declarative
+region and are routed through the PCS.
 
 Modify AARM E.2.3(16.a/3):
-   Aspect Description for All_Calls_Remote: All {direct} remote procedure
-   calls {from outside the declarative region of the RCI unit} should use
-   the Partition Communication Subsystem[, even if they  are local].
+   Aspect Description for All_Calls_Remote: All {indirect or dispatching remote 
+   procedure calls and all direct} remote procedure calls {from outside the 
+   declarative region of the RCI unit} should use the Partition Communication 
+   Subsystem[, even if they  are local].
 
 Modify E.2.3(19/3):
-   If aspect All_Calls_Remote is True for a given RCI library unit, then
-   the implementation shall route any {direct} call to a subprogram of
-   the RCI unit from outside the declarative region of the unit through
-   the Partition Communication Subsystem (PCS); see E.5. {Direct calls}
-   [Calls] to such subprograms from within the declarative region of the
-   unit are defined to be local and shall not go through the PCS.
+   If aspect All_Calls_Remote is True for a given RCI library unit, then the
+   implementation shall route any {indirect or dispatching remote subprogram 
+   call to the RCI unit or any direct} call to a subprogram of the RCI unit from
+   outside the declarative region of the unit through the Partition 
+   Communication Subsystem (PCS); see E.5. {Direct calls} [Calls] to such 
+   subprograms from within the declarative region of the unit are defined to be
+   local and shall not go through the PCS.
 
 Modify AARM E.2.3(19.a/3):
    When this aspect is False (or not used), it is presumed that most
-   implementations will {not involve the PCS}[make direct calls] if the
-   call originates in the same partition as that of the RCI unit. When
-   this aspect is True, all {direct} calls from outside the subsystem
-   rooted at the RCI unit package are treated like calls from outside the
-   partition, ensuring that the PCS is involved in all such calls (for
-   debugging, redundancy, etc.).
-
-Add to AARM E.2.3(19.b):
-  This aspect does not apply to indirect calls because the overhead
-  in determining whether an actual subprogram parameter is declared in
-  an All_Calls_Remote RCI unit or within the declarative region of
-  such a unit was deemed not to be worthwhile.
+   implementations will {not} make [direct] calls {through the PCS} if the call 
+   originates in the same partition as that of the RCI unit. When this aspect is
+   True, all {indirect or dispatching remote subprogram calls to the RCI unit 
+   and all direct} calls from outside the subsystem rooted at the RCI unit 
+   package are treated like calls from outside the partition, ensuring that the 
+   PCS is involved in all such calls (for debugging, redundancy, etc.).
+
+Modify AARM E.2.3(19.b):
+   Reason: There is no point to force local {direct} calls [(or calls from 
+   children)] to go through the PCS, since on the target system, these calls are 
+   always local, and all the units are in the same active partition. {
+   Indirect and dispatching calls however go through the PCS because the extra 
+   complications in determining whether the denoted subprogram is local to the 
+   All_Calls_Remote RCI unit was deemed to be too excessive. }
 
 !discussion
-
-Consider:
-
-package Server_RCI_Package is
-
-   pragma Remote_Call_Interface;
-
-   type Callback is access procedure;
-
-   procedure P (Call : Callback);
-
-end Server_RCI_Package;
-
-package body Server_RCI_Package is
-
-   procedure P (Call : Callback) is
-   begin
-      Call.all;
-      --  How can we tell if All_Calls_Remote applies to this call?
-   end P;
-
-end Server_RCI_Package;
-
-package Normal_RCI_Package is
-
-   pragma Remote_Call_Interface;
-
-   procedure Biff;
-
-end Normal_RCI_Package;
-
-package body Normal_RCI_Package is
-
-   procedure Biff is
-   begin
-      -- Do something
-      ...
-   end Biff;
-
-end Normal_RCI_Package;
-
-package All_Calls_Remote_Package is
 
-   pragma Remote_Call_Interface;
-   pragma All_Calls_Remote;
-
-   procedure Bam;
-
-end All_Calls_Remote_Package;
-
-package body All_Calls_Remote_Package is
-
-   procedure Bam is
-   begin
-      ...  -- Do something useful
-   end Bam;
-
-end All_Calls_Remote_Package;
-
-package All_Calls_Remote_Package.Child is
-
-   pragma Remote_Call_Interface;
-
-   type Callback is access procedure;
+The goal of the All_Calls_Remote aspect is to force calls from outside the
+declarative region of the RCI unit to go through the PCS. Calls that are local
+to the PCS should always be local and never go through the PCS. 
+
+This ideal is can be implemented easily enough for direct calls, but there are 
+excessive complications for the case of indirect or dispatching calls. In 
+particular, it would be difficult for the implementation to determine if a 
+remote access-to-subprogram value or a remote access-to-class-wide type value 
+denoted a subprogram that was local to the RCI unit, and thus whether the call
+should go through the PCS.
+
+To avoid these complications, we say that all indirect or dispatching remote 
+subprogram calls to an All_Calls_Remote RCI unit are assumed to be from outside
+the declarative region of the RCI unit, and therefore go through the PCS.
+
+This has the additional benefit that All_Calls_Remote means all calls are
+remote from outside the declarative region of the RCI. This eliminates the
+possibility for requests to rename the pragma to Almost_All_Calls_Remote, or
+There_Is_A_Possibility_That_The_Call_You_Make_To_This_Package_Could_Be_Remote, 
+etc.
 
-   procedure Pow (Cb : Callback);
-
-end All_Calls_Remote_Package.Child;
-
-package body All_Calls_Remote.Child is
-
-   procedure Pow (Cb : Callback) is
-   begin
-      Cb;
-      -- How can we tell if Cb is an All_Calls_Remote from within the
-      -- declarative region so that the call can be a local call?
-   end Pow;
-end All_Calls_Remote_Package.Child;
-
-with Server_RCI_Package;
-with All_Calls_Remote_Package.Child;
-with Normal_RCI_Package;
-
-procedure Distributed is
-begin
-   -- A => Call to All_Calls_Remote subprogam
-   Server_RCI_Package.P
-      (Call => All_Calls_Remote_Package.Bam'Access);
-
-   -- B => Call to Normal RCI subprogram
-   Server_RCI_Package.P
-      (Call => Normal_RCI_Package.Biff'Access);
-
-   -- C => Call to Child of All_Calls_Remote pkg with Parents subp
-   All_Calls_Remote_Package.Child.Pow
-      (Cb => All_Calls_Remote_Package.Bam'Access);
-
-   -- D => Call to Child of All_Calls_Remote pkg with subprogram
-   --      outside the declarative region of the parent package
-   All_Calls_Remote_Package.Child.Pow
-       (Cb => Normal_RCI_Package.Biff'Access);
-
-end Distributed;
-
-According to E.2.1 (19/3), the call at A => should be routed through
-the PCS, since the Bam subprogram is declared in an All_Calls_Remote
-package. However the call at B => presumably wouldn't go through the PCS
-if the Normal_RCI_Package and the Server_RCI_Package belonged to the
-same partition.
-
-In order for the body of Server_RCI.P to make this distinction,
-it would require a mechanism to determine whether the actual parameter
-was declared in an All_Call_Remotes RCI unit.
-
-Conversely, according to the latter part of E.2.1 (19/3), the call at
-C => should not be routed through the PCS, since the call is being made
-within the declarative region of the All_Calls_Remote RCI unit. However,
-the call at D=> would go through the PCS if Normal_RCI_Package belonged
-to a different partition than All_Calls_Remote_Package.
-
-The body of All_Calls_Remote_Package.Child.Pow would need to have a
-mechanism to determine whether the actual parameter is declared within
-the same declarative region, and if so, have a means to convert the
-remote subprogram address to the local direct subprogram address.
-
-Addressing these complications would involve introducing overhead for
-the calls and are not worth solving for a pragma that may be typically
-used only for debugging purposes.
-
-Instead, these complications can be avoided if the All_Calls_Remote
-pragma is clarified to only apply to direct calls to RCI units. It is
-up to the implementation to decide whether indirect calls to an RCI unit
-through a remote access-to-subprogram object in the same partition needs
-to be routed through the PCS.
-
-It was considered whether the pragma should be dropped from the standard
-altogether, since All_Calls_Remote is not entirely true if certain calls
-can be local. It was decided that it was worthwhile keeping the pragma
-because it is useful for debugging and testing a PCS, and because
-calls to an RCI unit are more typically direct calls.
-
 !ACATS test
 
 ** TBD.
@@ -344,5 +208,18 @@
 
 Based on this, I think perhaps that the AI as it was originally written up, is
 closer to what we want.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Friday, November 15, 2013  11:23 PM 
+
+Here is my homework. [This is version /03 of the AI - Editor.]
+
+In a nutshell,
+
+Indirect and dispatching calls to an All_Calls_Remote unit go through the PCS.
+Direct calls from outside the declarative region of the ACR unit go through the PCS.
+Local calls do not.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent