Version 1.1 of ai12s/ai12-0064-2.txt

Aspect and attribute Nonblocking are added.

During a protected action, it is a bounded error to invoke an operation that is potentially blocking. There is currently no mechanism (other than a comment) to specify that a given subprogram is intended to be safely callable during a protected action (i.e., that the subprogram will not invoke an operation that is potentially blocking). This seems like a useful part of a subprogram's "contract" that should be (optionally) specifiable at the point of a subprogram's declaration.

Modify 3.10.2(33/3):

Add after 4.6(24.21/4): [Type conversion Legality Rules for access-to-subprogram types]

[Editor's note: This was moved from Tucker's explicit wording; we're not scattering conversion rules all over the Standard.]

Add after 4.9(8):

Modify 9.5.1(11):

Add after 9.5.1(18):

[Editor's note: The above rewording is from the ARG meeting #54 minutes. But can't a primitive procedure of a limited interface type be implemented by an entry??? Nothing in the Legality Rules of 3.9.4 prevent it, and the example in 3.9.4 shows that it would be possible indirectly at a minimum. Consider that Append could be implemented by an entry for the synchronized interface in that example. Thus this rule needs to include limited interfaces (which, unfortunately, would effectively prevent them from being used in nonblocking contexts - unless we extended the aspect to interfaces, in which case we'd need some additional matching rules).]

[Editor's note: The above note was added to address Steve's concern about implicit calls.]

[Editor's note: I moved those rules, leaving this note for the language-lawyer reader.]

For a prefix S that denotes a subprogram (including a formal subprogram):

S'Nonblocking

For a prefix S that denotes an access-to-subprogram subtype (including formal access-to-subprogram subtypes):

S'Nonblocking

Wording Locations TBD:

[Editor's note: We might be able to do better here for untagged types, but sadly for tagged types we have to allow it to be potentially blocking as some overriding might need it (and all of the overridings need to be the same).]

[Editor's note: We intend that language-defined subprograms are nonblocking unless this Standard says otherwise. Specifically, 9.5.1(18) says:

We'll accomplish that by adding "with Nonblocking => True" to all of the language-defined packages unless otherwise noted here.

We don't need to add that to units that are non-generic and declared pure, as those already default to True.

For generic units that have formal subprograms (like the Ada.Containers packages), the package would instead have "with Nonblocking => Formal1'Nonblocking and Formal2'Nonblocking and ...;". This automatically matches the nonblocking setting to that of the actual subprograms (see the !discussion for more on this).

The I/O packages are potentially blocking (Nonblocking => False), but we will mark the Put/Get routines that put into a string or get from a string as Nonblocking (see the first !example).

There are special cases where subprograms are specifically marked as

* individual subprograms identified in the Standard as potentially blocking; * subprograms with anonymous-access-to-subprogram parameters (else we would

Writing the exact text for this can wait until the larger details are worked out. In the case of the containers, it may make more sense to include those contracts in the AI that defines preconditions for the container operations; it probably makes the most sense to add all of the contracts at once.

End lengthy editor's note.]

We considered changing the aspect name from "Nonblocking" to "Potentially_Blocking," as that matches RM terminology better, but we ultimately concluded that would be a mistake. Furthermore, "nonblocking" is used in 9.5.1, albeit somewhat informally. Were we to switch to Potentially_Blocking, the default would be True rather than False, which is unlike other Boolean aspects. Furthermore, with Potentially_Blocking => True, we wouldn't require that it be potentially blocking, merely allow it. Perhaps Allow_Blocking would be better, but that doesn't match RM terminology at all, and still has the "wrong" default.

We initially modeled this aspect after No_Return, which has a somewhat similar purpose and presumably has already worked out some of the needed rules. However, we have gone beyond that, because we now have nonblocking access-to-subprogram types, nonblocking formal subprograms, etc.

The rules do not allow calling "normal" subprograms from a nonblocking subprogram. This allows detecting any potentially blocking operations used in a nonblocking subprogram statically. This is important if pragma Detect_Blocking is used, as such detection is required. (Otherwise, this is just a bounded error and the "mistake" can be ignored with the usual consequences.)

We have provided package-level defaults, given that many packages will have all of their subprograms non-blocking. We chose to make the default for a declared pure, non-generic library unit to be nonblocking, as that is almost always the case, since blocking typically implies the use of some kind of global lock. We do not foresee significant incompatibilities, since declared pure library units may only depend on other declared pure library units. For pure generic units we leave the default at False for compatibility reasons, because these might have existing instances where an actual subprogram (or access-to-subprogram type) is potentially blocking.

We did not specify that protected subprograms are by default Nonblocking=>True, since that would be incompatible, as they then could not call subprograms with a default Nonblocking aspect value of False. It might be possible to specify Nonblocking=>True as the default for protected subprograms in a future version of the standard (and clearly an implementation could at least provide a warning when a call is made to a subprogram with Nonblocking of False). Because of the confusion related to the fact that protected operations are always required to be nonblocking at run-time, we don't allow specifying the attribute directly on an individual protected operation. However, we allow specifying Nonblocking on a protected unit to determine the setting for all of the enclosed protected operations.

We only allow specifying a confirming value of Nonblocking on a generic instantiation; the value of the aspect comes from the generic unit (possibly after re-evaluating the aspect based on the values of the actual parameters). Specifying a different value would simply be confusing, as it wouldn't change the enforcement of Legality Rules in the generic unit (and it would be wrong to supply a value of True for an instance of a unit that have the value of False, as in that case no rules would have been enforced in the body).

----

The attribute Nonblocking is primarily useful for use in the Nonblocking aspect of other subprograms, and mainly for the non-blocking property of formal subprograms.

We allow the prefix to be any subprogram to avoid having special cases, and as it may be useful to ensure that a group of subprograms all have the same contract. In the case of nonblocking, that could be accomplished with a constant, but in the case of other static contracts that we are considering like exception contracts (AI12-0015-1) and global contracts (AI12-0079-1), a mechanism to copy them will be valuable (especially as they may be lengthy). As we want all of the contracts to work as similarly as possible, we make the attribute Nonblocking as general as possible.

The primary use for this attribute is in aspects of generic units. The attribute makes it possible for a generic unit to have a nonblocking aspect that depends on those of the actual subprograms. That's especially important for the containers, which we want to be primarily nonblocking.

This mechanism takes some effort for the implementer of a generic unit, but it means that the instantiator of such a unit does not need to worry about nonblocking, as the most restrictive setting compatable with the actual subprograms will automatically be chosen.

Unfortunately, this mechanism doesn't have an obvious extension to support anonymous access-to-subprogram parameters; the type is anonymous and the actual is typically an Access attribute. One could imagine allowing the prefix to be a parameter, something like:

But in that case the Nonblocking value would have to be determined based on the actuals of the call; it would be weird for the Legality of a call to depend on the details of actual parameters. Thus we didn't propose such a mechanism.

----

We could simplify this proposal further by dropping the ability to specify Nonblocking on generic formal parameters, and just depending on the Nonblocking aspect to handle that. That would eliminate the rules about generic formal matching. We didn't do that as that would require having nonblocking attributes for formal packages and formal objects (which would reduce the value somewhat), and would eliminate the "easy" solution for new code (which is to simply require everything to be nonblocking). Not everyone needs to write the most flexible possible generics.

---

Comparing Alternative 1 with this proposal.

The problem with alternative 1 is that a generic unit like the containers can be set to nonblocking, but then using this with a not nonblocking routine requires an explicit override by the user on the instance. Since the default for most routines is that they are not nonblocking, this could provide a significant compatibility problem.

An alternative for alternative 1 would be to declare units like the containers to be blocking; but then they can never be nonblocking (and we surely want to use them as blocking).

In contrast, this proposal puts all of the burden on the implementer of a package (where it should be) and none on the user of the package. Alternative 1 is definitely easier for the implementer of a package, and harder for a user.

Container usage examples:

Imagine that a user has an existing user-defined Hash function:

With this proposal (as outlined in the example section below), if they don't care about nonblocking (as is likely to be the case for recompiling existing code), their existing instantation will compile with no problem:

If they do care about blocking behavior, they can add Nonblocking to Hash and they will get the Nonblocking behavior they want:

Alternatively, they could declare the instance to be Nonblocking:

which would cause an error (as Nonblocking is False), hopefully with an error message that Hash has Nonblocking set as False (since that's the default). With a good error message, the correct fix should be easy to find.

-------------------

For alternative 1 (as described in AI12-0064-1/05), the situation is different.

The original instantation of:

is now illegal, as Hash has Nonblocking = False, and that fails to match the default for the formal parameter Hash (which is Nonblocking => True). Thus the user has to change their code and add Nonblocking => True to Hash or add Nonblocking => False to the instance My_Hashed_Map.

That doesn't seem good.

If the default of Ada.Containers.Hashed_Map is changed to False, then the above works, but there no longer is any way to get a Nonblocking container.

should be illegal in this case, as the restrictions were not enforced in the generic body.

---------------

There is one known problem with this proposal as it is written. The prefix of the Nonblocking attribute has to resolve without any context. That means that in many circumstances, overloaded prefixes aren't going to be usable. That could be a huge problem for operators (like "=" in the containers) that are widely used.

I considered using subprogram calls rather than subprogram names in the prefix, but that ran into issues both with having appropriate parameters to use (in the generic case) and with evaluation of the prefix (which we don't want to do).

I also consider using qualification, but that doesn't help for relational operators (they all return Boolean!).

The problem could be reduced somewhat by only allowing formal subprograms as the prefix of Nonblocking, but that is not a complete fix and does reduce the capability somewhat. In particular, both the inner and outer generics in Ordered_Sets have a formal "<" operator; it wouldn't be possible to refer to "<"'Nonblocking inside the nested generic.

One of course can avoid using operators in generic specifications, but that's impractical for existing generics and a usage pain for new generics.

I'm at a loss for other ideas to try at this point, short of some sort of profile in the prefix (something we've managed to avoid up to this point in the development of Ada).

Alternatively, we could separately specify the blocking for the individual routines, depending on which of the formal routines they are allowed to use. (Given that we leave that unspecified in the Standard, it's probably better to use a global setting as was done here.)

TBD.

ACATS B-Tests and C-Tests.

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