Version 1.6 of ais/ai-00178.txt
!standard 09.05.01 (18) 03-05-03 AI95-00178/04
!class ramification 03-01-10
!status WG9 approved 03-06-20
!status ARG Approved 8-0-0 03-02-09
!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 "manipulate 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 narrower interpretation be 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 operations 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 be 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.
!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?
****************************************************************
From: Randy Brukardt
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.
At the 18th Meeting of the ARG, we decided not to do this, as the wording
is insufficiently broken.
****************************************************************
Questions? Ask the ACAA Technical Agent