Version 1.5 of ai12s/ai12-0283-1.txt

Unformatted version of ai12s/ai12-0283-1.txt version 1.5
Other versions for file ai12s/ai12-0283-1.txt

!standard E.2.2(9.3/1)          18-08-31 AI12-0283-1/03
!standard E.2.3(13/3)
!standard E.4(8)
!class Amendment 18-06-11
!status Amendment 1-2012 18-07-12
!status WG9 Approved 16-10-22
!status ARG Approved 8-0-3 18-06-23
!status work item 18-06-11
!status received 18-05-15
!priority Low
!difficulty Easy
!subject Nonblocking and remote calls
!summary
Remote types and remote subprograms cannot be declared nonblocking.
!problem
E.4(17) says:
All forms of remote subprogram calls are potentially blocking operations (see 9.5).
However, this is necessarily not reflected in the value of the Nonblocking aspect for remote access types and remote subprograms. That would potentially allow a blocking operation in statically checked nonblocking code.
For instance:
package R with Remote_Types, Nonblocking is type A is access procedure; -- OK? (No.) end R;
A dereference of type A is a remote call, and thus is potentially blocking. Yet the declaration above would allow such a call to occur in a protected type with Nonblocking set to True. That would defeat the purpose of the static checking. Is the above legal? (No.)
!proposal
(See Summary.)
!wording
[Editor's note: These are all in Legality Rules sections. None of these subclauses have static semantic sections, and that appears to have been done by the Ada 95 authors to avoid needing Notwithstanding rules.]
Add after E.2.2(9.3/1):
A remote access-to-subprogram type shall not be nonblocking (see 9.5).
AARM Reason: All calls on remote subprograms are considered potentially blocking, so they cannot statically be allowed in nonblocking code.
AARM Ramification: The type declaration of a remote type is illegal if the Nonblocking aspect is True, either implicitly by inheritance or by explicit specification.
Add after E.2.3(13/3):
* it shall not be, nor shall its visible part contain, the declaration of a subprogram that is nonblocking (see 9.5);
AARM Reason: All such subprograms are remote subprograms, and all calls on remote subprograms are considered potentially blocking, so they cannot statically be allowed in nonblocking code.
AARM Ramification: The declaration of a remote subprogram is illegal if the Nonblocking aspect is True, either implicitly by inheritance or by explicit specification.
Add after E.4(8):
A nonblocking program unit shall not contain, other than within nested units with Nonblocking specified as statically False, a dispatching call with a controlling operand designated by a value of a remote access-to-class-wide type.
AARM Reason: Such a dispatching call is a potentially blocking call (see below) even if the called subprogram is nonblocking, so we must not assert that no blocking is possible.
AARM Ramification: The call is illegal if the Nonblocking aspect of the containing unit is True, either implicitly by inheritance or by explicit specification.
[Editor's note: A cross-reference is included in each of these rules to emphasize that "nonblocking" and "allows blocking" are technical terms defined in 9.5.]
!discussion
This AI is a correction for AI12-0064-2 (which introduces aspect Nonblocking), which was previously approved for Ada 2012.
---
E.4(17) says that remote calls are always potentially blocking. This needs to be reflected in the static value of the Nonblocking aspect - we don't want anything that is potentially blocking to have Nonblocking True.
We choose to define this using Legality Rules as that is the style of the existing categorization restrictions. We could have alternatively defined Nonblocking to be False for all such subprograms and types, but that would have required a number of Notwithstanding Rules.
These rules are compatible, as the default value for Nonblocking (if not specified anywhere in a library unit) is False. One can only get failures if the entity or the enclosing package has been specified to be nonblocking.
!corrigendum E.2.2(9.3/1)
Insert after the paragraph:
A type that is derived from a remote access type is also a remote access type.
the new paragraph:
A remote access-to-subprogram type shall not be nonblocking (see 9.5).
!corrigendum E.2.3(13/3)
Insert after the paragraph:
the new paragraph:
!corrigendum E.4(8)
Insert after the paragraph:
In a dispatching call with two or more controlling operands, if one controlling operand is designated by a value of a remote access-to-class-wide type, then all shall be.
the new paragraph:
A nonblocking program unit shall not contain, other than within nested units with Nonblocking specified as statically False, a dispatching call with a controlling operand designated by a value of a remote access-to-class-wide type.
!ASIS
No change needed.
!ACATS test
ACATS B-Tests are needed to check that the new rules are enforced.
!appendix

From: Randy Brukardt
Sent: Tuesday, May 15, 2018  2:56 PM

Tullio's note pointed out E.4(17):

All forms of remote subprogram calls are potentially blocking operations
(see 9.5). 

[Note: I fixed the reference in the presentation AI.]

However, this not reflected in the value of Nonblocking for such calls. 
That means that a remote subprogram could have Nonblocking => True if it
otherwise meets the requirements. We probably need to add some wording 
somewhere (either in 9.5 or in annex E to treat remote subprograms like 
entries.

For instance, in E.2.2 we probably should add something like:

The following restrictions apply to the use of a remote access-to-subprogram
type: 

   {* The Nonblocking aspect shall be False (implicitly or explicitly);}

   AARM Reason: All calls on remote subprograms are considered potentially 
   blocking, so they cannot statically be allowed in Nonblocking code.

Similarly, in E.2.3 we ought to add something like:
   The Nonblocking aspect of a remote subprogram shall be True.

   AARM Reason: All calls on remote subprograms are considered potentially 
   blocking, so they cannot statically be allowed in Nonblocking code.

Finally, we would need something like the following in E.4:

   A dispatching call with a controlling operand designated by a value of a
   remote access-to-class-wide type shall be to a subprogram with 
   Nonblocking => False.

   AARM Reason: This is a potentially blocking call (see below), so we must 
   not assert that no blocking is possible.

[I don't see a sane way to require this at the type declaration, since that 
itself may not be declared remote. Thus it has to be enforced on the call. I
suppose an alternative would be to do the enforcement of the other two cases
on the call as well -- which would allow local nonblocking calls -- but that
seems an unlikely usage.]

These are all Legality Rules. I believe that these are all compatible with 
existing Ada code, as Nonblocking is always False unless explicitly set. So
existing code that never uses Nonblocking cannot violate any of these rules.

Thoughts??

****************************************************************

From: Tucker Taft
Sent: Tuesday, May 15, 2018  3:39 PM

> For instance, in E.2.2 we probably should add something like:
> 
> The following restrictions apply to the use of a remote 
> access-to-subprogram
> type: 
> 
>   {* The Nonblocking aspect shall be False (implicitly or 
> explicitly);}

This is one of those "shall be"s that should probably be simply "is". 
Elsewhere we could say that only confirming specifications are permitted.

> 
>   AARM Reason: All calls on remote subprograms are considered 
> potentially blocking, so they cannot statically be allowed in Nonblocking code.
> 
> Similarly, in E.2.3 we ought to add something like:
>   The Nonblocking aspect of a remote subprogram shall be True.

Probably "is" rather than "shall be" here as well.

>   AARM Reason: All calls on remote subprograms are considered 
> potentially blocking, so they cannot statically be allowed in Nonblocking code.
> 
> Finally, we would need something like the following in E.4:
> 
>   A dispatching call with a controlling operand designated by a value 
> of a remote access-to-class-wide type shall be to a subprogram with 
> Nonblocking => False.
> 
>   AARM Reason: This is a potentially blocking call (see below), so we 
> must not assert that no blocking is possible.
> 
> [I don't see a sane way to require this at the type declaration, since 
> that itself may not be declared remote. Thus it has to be enforced on 
> the call. I suppose an alternative would be to do the enforcement of 
> the other two cases on the call as well -- which would allow local 
> nonblocking calls -- but that seems an unlikely usage.]
> 
> These are all Legality Rules. I believe that these are all compatible 
> with existing Ada code, as Nonblocking is always False unless 
> explicitly set. So existing code that never uses Nonblocking cannot violate
> any of these rules.
> 
> Thoughts??

As indicated above, the rules about the value of the Nonblocking aspect should 
probably be static semantics rules, not legality rules.

****************************************************************

From: Randy Brukardt
Sent: Tuesday, May 15, 2018  3:56 PM

...
> As indicated above, the rules about the value of the Nonblocking 
> aspect should probably be static semantics rules, not legality rules.

That was my original thought, but that's not how E.2.2 and E.2.3 are written 
for other properties. For instance, the header I showed in E.2.2 is a Legality
Rule with 2 existing bullets, and I was proposing to add a third bullet to it.
Trying to redefine the definition of Nonblocking in that case would have been 
possible, but it would be different than the way other properties like the 
value of the type are defined. (Also, there's no Static Semantics section in
E.2.2 and E.2.3).

It appears to me that the Annex just adds additional requirements as Legality
Rules, rather than trying to change the definition of things to meet the 
remote needs. I thought it was best to follow the same pattern.
That way, something like:

    package R with Remote_Types, Nonblocking is
        type A is access procedure; -- Illegal, Nonblocking = True is 
                                    -- inherited from enclosing unit.

        type B is access procedure with Nonblocking => False; -- OK.
    end R;

doesn't need "notwithstanding" rules all over the place.

***************************************************************

From: Tuillo Vardanega
Sent: Thursday, May 17, 2018  6:47 AM

The intricacies of how to present this in RM-ese are beyond me, but I concur
with Randy's line of argument.

****************************************************************


Questions? Ask the ACAA Technical Agent