Version 1.1 of ai12s/ai12-0283-1.txt
!standard E.2.2(9.3/1) 18-06-11 AI12-0283-1/01
!standard E.2.3(13/3)
!standard 5.5.2(7/3)
!class Amendment 18-06-11
!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; --
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 intentional
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 contain or be itself a remote subprogram that is
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 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 dispatching call with a controlling operand designated by a value of a
remote access-to-class-wide type shall be to a subprogram that allows
blocking (see 9.5).
AARM Reason: This is a potentially blocking call (see below), so we must
not assert that no blocking is possible.
AARM Ramification: The call is illegal if the Nonblocking aspect
of the called subprogram is True, either implicitly by inheritance or
by explicit specification. Note that if subprogram is nonblocking,
all overridings (and inherited versions) of that subprogram also
have to be nonblocking.
[Editor's note: I included a cross-reference 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 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 to be potentially blocking that has 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 it 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.
!ASIS
[Not sure. It seems like some new capabilities might be needed,
but I didn't check - Editor.]
!ACATS test
ACATS B- and C-Tests are needed to check that the new capabilities are
supported.
!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