Version 1.3 of ais/ai-00178.txt

Unformatted version of ais/ai-00178.txt version 1.3
Other versions for file ais/ai-00178.txt

!standard 09.05.01 (18)          03-01-10 AI95-00178/02
!class ramification 03-01-10
!status work item 99-09-18
!status received 97-03-19
!priority Low
!difficulty Medium
!subject Which I/O operations are potentially blocking?
!summary
All subprograms that manipulate files (implicitly or explicitly) defined in language-defined input-output packages are potentially blocking.
Any subprogram that has a file parameter or result or operates on a default file is considered to manipulate a file.
!question
9.5.1(18) states that "the subprograms of the language-defined input-output packages that manipulate files (implicitly or explicitly) are potentially blocking." It is not clear what this means.
1. Is "that manipulate files" meant to modify "subprograms" (in which case the versions of Put that write to strings are excluded) or "packages" (in which case these versions of Put might be included, but see #2). ("Subprograms".)
2. Is a subprogram provided by an instance of a generic package nested in Ada.Text_IO considered a subprogram "of" Ada.Text_IO? (Yes.)
3. Which subprograms are considered to "manipulate files"? Is any subprogram with a File_Type parameter, plus any counterpart that operates in the same way on a default file, considered to "manuipulate files", or is manipulation of files restricted to subprograms that perform what A.8.2 calls "File Management"? Indeed, are the file-management functions that query properties of an internal file (Mode, Name, Form, Is_Open) considered to manipulate files? (Yes.)
!response
In order to answer the first question, we'll need to first think about the meaning of "manipulate files" (and thus answer the third question).
The wording of 9.5.1(18) just says "manipulate files" and does not put any restrictions on the subprograms covered. Thus a broad interpretation seems intended.
Could a more narrow intpretation been intended? It is clear that any subprogram that might call an operating system service to read or modify an external file has to be considered potentially blocking, since such a call can take an arbitrary amount of time to complete. This includes the file management operations (Create, Open, Close, etc.) as well as the operation that read or modify the contents of the file (Read, Write, Flush, etc.).
There are operations, like Form, Line_Length, etc., which probably don't need to call any system service, but can merely be implemented by retrieving information from some data structure associated with the File_Type object. However, for an implementation that would support concurrent access to internal files, accessing this data structure would require some synchronization (e.g., to ensure that any file management operation in progress has completed), and the synchronization itself would be potentially blocking (for instance it could be implemented by entry calls). We don't want to prevent an implementation from supporting concurrent access to a given file object (although we don't require it; see RM95 A(3)).
Thus, it seems that any subprogram with a File_Type parameter and any subprogram that operates implicitly on a default file should be potentially blocking. That matches the broad, simple wording of the paragraph, and thus we conclude that that is the meaning and intent of 9.5.1(18).
Having answered the third question, let's turn to the second question. Clearly, the wording of 9.5.1(18) covers the generic packages nested in Ada.Text_IO, as well as Ada.Sequential_IO and Ada.Direct_IO. These clearly are "language-defined input-output packages"; the fact that they are generic or nested or both doesn't change that status.
Are instances of those packages covered? If they are not, we would have some file manipulation subprograms that were not covered by this paragraph. Clearly, for all of the reasons mentioned previously, that would wrong and contrary to the intent of the paragraph. Thus, we conclude that such instances are covered by this paragraph and thus may contain potentially blocking subprograms.
Finally, let's turn to the first question. The packages Ada.Text_IO, Ada.Wide_Text_IO, Ada.Sequential_IO, Ada.Direct_IO, Ada.Streams.Stream_IO, and the nested and child packages of them, all contain subprograms that manipulate files. All subprograms that manipulate files are included by either reading of 9.5.1(18). For all of these packages, the only subprograms that do not have either a File_Type parameter or result, and do not manipulate a default file, are the Get and Put procedures that read from/write to a string defined in the nested packages of Ada.Text_IO (and Ada.Wide_Text_IO).
Thus, this question boils down to whether those Get and Put procedures are potentially blocking. These routines really have no relationship whatsoever with IO: they are just string manipulation operations. There is no implementation reason that they need to be potentially blocking. Moreover, it would be preferable if they were consistent with the other string operations defined by the standard (the operations in the string packages Ada.Strings.Fixed and the like).
Therefore, we adopt the less restrictive interpretation.
We have not previously discussed Ada.Storage_IO. While its name suggests that it may be included under this rule, it in fact contains no subprograms that manipulate files (it only manipulates in-memory byte strings). Therefore, its operations are not potentially blocking.
[Editor's note: I'd prefer to clarify the wording of 9.5.1(18) as in the summary: "All subprograms that manipulate files (implicitly or explicitly) defined in language-defined input-output packages are potentially blocking. Any subprogram that has a file parameter or result or operates on a default file is considered to manipulate a file." This is not strictly necessary, but would avoid confusion, particularly about the status of the subprograms in the nested Text_IO packages that take strings. But it would be weird to modify normative wording in a ramification, so I didn't do it in this version.]
!appendix

!section 9.5.1(18)
!subject Which I/O operations are potentially blocking?
!reference RM95-9.5.1(18)
!from Norman Cohen
!reference 97-15708.a Norman H. Cohen 97-1-22>>
!discussion

9.5.1(18) states that "the subprograms of the language-defined input-output
packages that manipulate files (implicitly or explicitly) are potentially
blocking."  It is not clear what this means.

1.  Is "that manipulate files" meant to modify "subprograms" (in which case
the versions of Put that write to strings are excluded) or "packages" (in
which case these versions of Put might be included, but see #2).

2. Is a subprogram provided by an instance of a generic package nested in
Ada.Text_IO considered a subprogram "of" Ada.Text_IO?

3. Which subprograms are considered to "manipulate files"? Is any
subprogram with a File_Type parameter, plus any counterpart that operates
in the same way on a default file, considered to "manuipulate files", or is
manipulation of files restricted to subprograms that perform what A.8.2
calls "File Management"?  Indeed, are the file-management functions that
query properties of an internal file (Mode, Name, Form, Is_Open) considered
to manipulate files?

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

Questions? Ask the ACAA Technical Agent