!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; -- 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 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. ****************************************************************