!standard 9.5.1(18) 13-11-12 AI12-0064-1/02 !class Amendment 13-04-22 !status work item 13-04-22 !status received 13-04-22 !priority Medium !difficulty Medium !subject Nonblocking subprograms !summary Aspect Nonblocking is added. !problem 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. !proposal Add an aspect Nonblocking. !wording Add at the end of 9.5.1 (as continuation of bounded error section?) For a callable entity or a generic subprogram, the following language-defined representation aspect may be specified: The type of aspect Nonblocking is Boolean. When aspect Nonblocking is True for an entity, the entity is said to be nonblocking. If directly specified, the aspect_definition shall be a static expression. [This aspect is never inherited;] if not directly specified, the aspect is False. When a callable entity is nonblocking, a call to the entity is considered to be within a protected operation for purposes of the check described above that is associated with invoking an operation that is potentially blocking (including interactions with pragma Detect_Blocking (see H.5)). In addition, a call to an entity that is not a nonblocking entity is considered potentially blocking for the purposes of the check. AARM Ramification: This implies, if Detect_Blocking is set, that calling a potentially blocking operation from the body of Nonblocking subprogram raises Program_Error. That includes calling any non-nonblocking subprograms. AARM Implementation Note: We make calling non-nonblocking subprograms from the body of a nonblocking subprogram a bounded error so that the check can be made statically in the case that pragma Detect_Blocking is in force. We certainly do not want distributed overhead in the case where pragma Detect_Blocking is in force, a nonblocking subprogram that is called from outside of a protected action then calls a normal subprogram that uses a potentially blocking operation (this case would require an extra TCB flag or the like to be reliably detected, which is required in the presence of the pragma). A subprogram shall be nonblocking if it overrides a dispatching nonblocking procedure. In addition to the places where Legality Rules normally apply (see 12.3), this rule applies also in the private part of an instance of a generic unit. !discussion We've modeled this aspect after No_Return, which has a similar purpose and presumably has already worked out the needed rules. For this reason, we don't have nonblocking access-to-subprogram types. One could imagine such a thing, but it would take a number of additional rules and certainly wouldn't be "keeping it simple". 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.) !example TBD. !ASIS TBD. !ACATS test ACATS B-Tests (to test 4.3.3(17-18) and the new rules) and C-Tests. !appendix ****************************************************************