08-122r1 To: J3 From: Malcolm Cohen Subject: Interpretation request: ID= integer size Date: 2008 February 14 NUMBER: F03/0113 TITLE: Size and uniqueness considerations for ID=. KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: The ID= specifier returns an identifier (or "handle") for an async i/o request. Must this fit inside the smallest integer kind supported by the processor? Consider: Integer(Selected_Int_Kind(1)) x(1000) Character(80) :: test(1000) = (/ ... /) ... Do i=1,1000 Write (17,'(a)',Asynchronous='Yes',Id=x(i)) test(i) End Do ... Do i=1,1000 Wait (17,Id=i) End Do X is only guaranteed to have approximately 20 values available, and in practice will probably only have 256 such values, so we are certainly not going to have 1000 unique handles. Without loss of generality, suppose that one such duplicate value is 4. After WAIT(17,ID=4), the async i/o request with ID 4 is no longer pending. This means that the subsequent WAIT(17,ID=4) is not conforming to the standard since it requires that the ID= value is one that is pending. (1) Is the processor permitted to require a minimum size for ID= (e.g. such as default integer)? Clearly 1000 values do not fit into a 256-valued object, but apart from that, (2) Is the processor required to produce unique ID= values for each multiple asynchronous i/o operation? One might conjecture that if the processor returned ID=4 for two or more async i/o requests on the same unit, the first WAIT for ID=4 would wait for the first such async i/o request and the second one would wait for the second such async i/o request. (3) Does WAIT-ing on an ID= value wait for all async i/o operations that have that as the handle, or are these queued up? Unlike other i/o-related specifiers, there does not seem to be any constraint on the value returned for ID= (such as being non-zero or non-negative). In the case of the i/o being completed synchronously, there does not appear to be any way of returning a "non-handle" to the user program (one might have conjectured that zero was not a handle, but this is not supported by the text of the standard). (4) Was there intended to be a "non-handle" return for ID=? DISCUSSION: It is understood that resource considerations may limit the number of outstanding asynchronous i/o requests, but 19 (the limit implied by the minimum-size integer that follows the model in c13) seems awfully small; for that matter 256 seems pretty small for todays operating systems. ANSWER: (1) Yes, the standard should require the ID= specifier to be default integer or bigger. An edit is provided. (2) Yes, all pending data transfer operation identifiers on a particular unit are required to be unique. An edit is provided to clarify this. (3) ID= values are required to be unique, so this question does not arise. (4) Yes, the value zero should not be a handle but an indication the request was completed synchronously. An edit is provided to add this. EDITS: In 9.5.1 Control information list, [187:2] "ID = " -> "ID = " [187:10+] Insert new BNF rule and constraint "R913a <> C908a (R913a) shall be have a decimal range no smaller than that of default integer." {Require default integer or larger.} In 9.5.1.8 ID= specifier in a data transfer statement [190:17] Change "This value" to "If this value is zero, the data transfer operation has been completed. A nonzero value" {Zero = "it was done synchronously already" value.} [190:18] After "operation." insert "This identifier is different from the identifier of any other pending data transfer operation for this unit." {Require uniqueness.} [206:18] Before "the identifier" insert "zero or". [206:20] After "operation" insert ", if any,". {Make ID=zero do nothing in WAIT.} SUBMITTED BY: Malcolm Cohen HISTORY: 08-122 m183 F03/0113 Submitted 08-122r1 m183 Draft answer