From ajosey@rdg.opengroup.org Mon Mar 30 13:09:23 1998 Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by dkuug.dk (8.6.12/8.6.12) with SMTP id NAA05613 for ; Mon, 30 Mar 1998 13:09:21 +0200 Received: by mailgate.rdg.opengroup.org; id AA28147; Mon, 30 Mar 1998 11:08:36 GMT Message-Id: <9803301108.AA28147@mailgate.rdg.opengroup.org> Received: from mailhome [192.153.166.5] by mailgate.rdg.opengroup.org via smtpd ; Mon Mar 30 11:08 GMT 1998 Received: by mailhome.rdg.opengroup.org (1.36.108.10/16.2) id AA15800; Mon, 30 Mar 1998 12:08:00 +0100 From: ajosey@rdg.opengroup.org (Andrew Josey) Date: Mon, 30 Mar 1998 12:08:00 +0100 Reply-To: ajosey@rdg.opengroup.org (Andrew Josey) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: sc22wg15@dkuug.dk Subject: Defect Report concerning: IEEE Std. 1003.1c-1995, ISO/IEC 9945-1:1990 AMD 2 - Threads For the attention of the WG15 Project Editors: Defect Report concerning: IEEE Std. 1003.1c-1995, ISO/IEC 9945-1:1990 AMD 2 - Threads Defect report number: IS9945-1:1996 #1c-43 Clause: 13.5.1.2 PASC Interpretation Ref: pasc-1003.1c-43 Topic: PTHREAD_PRIORITY_SCHEDULING and ENOSYS ---------------------------------------------------------------------------- 1003.1c-95 #43 _____________________________________________________________________________ Interpretation Number: XXXX Topic: PTHREAD_PRIORITY_SCHEDULING and ENOSYS Relevant Sections: 13.5.1.2 WG15 Status Block: ------------------------------------------------------------------------ 1 Defect report number: IS9945-1:1996 #1c-43 2 Submitter: IEEE PASC Mar 30 1998 3 Addressed to: JTC1/SC22 /WG15 editor's group on IS 9945-1 4 WG secretariat: ------------------------------------------------------------------------ 5 Date circulated by WG secretariat: 6 Deadline on response from editor: 7 Defect Report concerning (number and title of International Standard or DIS final text): IEEE Std. 1003.1c-1995, ISO/IEC 9945-1:1990 AMD 2 - Threads Clause: 13.5.1.2 8 Qualifier (e.g. error, omission, clarification required): clarification required 9 References in document (e.g. page, clause, figure, and/or table numbers): Clause: 13.5.1.2 10 Nature of defect (complete, concise explanation of the perceived problem): See attached ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): None. ------------------------------------------------------------------------ 12 Editor's response (any material proposed for processing as a technical corrigendum to, an amendment to, or a commentary on the International Standard or DIS final text is attached separately to this completed report): See interpretation response attached ------------------------------------------------------------------------ Interpretation Request: (Defect Report) ----------------------- From: Andrew Josey (on behalf of the X/Open Base working group) Interpretation Request for: IEEE Std 1003.1c-1995 as contained in: ISO/IEC 9945-1:1996(E), ANSI/IEEE Std. 1003.1, 1996 Edition. We have the following questions about conformance. Taking a function such as pthread_attr_setscope(), for example, 9945-1:1996, p300, 13.5.1.2 states: If _POSIX_THREAD_PRIORITY_SCHEDULING is defined: requirements are listed . . Otherwise: Either the implementation shall support the pthread_attr_setscope function as described above, or the function shall not be provided. Then section 13.5.1.4 specifies a permitted return value of ENOSYS when the implementation does not support the pthread_attr_setscope() function. 1. Is a system which defines _POSIX_THREAD_PRIORITY_SCHEDULING and provides an implementation of pthread_attr_setscope() which always returns ENOSYS conformant ? 2. Is a system which does NOT define _POSIX_THREAD_PRIORITY_SCHEDULING and provides an implementation of pthread_attr_setscope() which always returns ENOSYS conformant ? 3. Is a system which does NOT define _POSIX_THREAD_PRIORITY_SCHEDULING and provides an implementation of pthread_attr_setscope() which meets the requirements specified in 13.5.1.2 9945-1:1996 conformant ? 4. Does the ENOSYS return value exist because the provision of the _POSIX_THREAD_PRIORITY_SCHEDULING feature may be run-time dependent (available at times and unavailable at others) ? Interpretation response ----------------------- > 1. Is a system which defines _POSIX_THREAD_PRIORITY_SCHEDULING and > provides an implementation of pthread_attr_setscope() which always > returns ENOSYS conformant ? > No. > 2. Is a system which does NOT define _POSIX_THREAD_PRIORITY_SCHEDULING > and provides an implementation of pthread_attr_setscope() which > always returns ENOSYS conformant ? > Yes. The standard appears to permit three distinct conforming implementation behaviors when _POSIX_THREAD_PRIORITY_SCHEDULING is not defined: (a) Functions such as pthread_attr_setscope() are not provided by the implementation, and any attempt to use them will cause compile and/or link-time errors. (b) Functions such as pthread_attr_setscope() are provided by the implementation and behave as defined in the case when _POSIX_THREAD_PRIORITY_SCHEDULING is defined. (c) Functions such as pthread_attr_setscope() are provided by the implementation as stubs returning ENOSYS. However, note that concerns have been raised about item (c) which are being forwarded to the sponsor. See the rationale for more discussion of this topic. > 3. Is a system which does NOT define _POSIX_THREAD_PRIORITY_SCHEDULING > and provides an implementation of pthread_attr_setscope() which meets > the requirements specified in 13.5.1.2 9945-1:1996 conformant ? > Yes. > 4. Does the ENOSYS return value exist because the provision of the > _POSIX_THREAD_PRIORITY_SCHEDULING feature may be run-time > dependent (available at times and unavailable at others) ? > No. It exists because of an editorial mistake while drafting the text of the standard. ENOSYS error returns were permitted for pthreads functions in previous drafts of the text, before the "Otherwise" clauses in lines such as p. 302, lines 558-562 were amended to read "Otherwise: Either the implementation shall support the ... functions as described above or the ... functions shall not be provided". The editorial mistake was that we failed to delete the ENOSYS lines from the optional functions related to thread scheduling. Concerns are being forwarded to the sponsor. See the rationale below for further discussion. Rationale ------------- The intent of the standard was to prohibit non-working versions of pthreads functions in conforming implementations, independent of which options are defined. However, this intent was not unambiguously achieved for those functions such as pthread_attr_setscope() where an ENOSYS error return was described. It is recommended that a future revision clarify the requirements for these cases. Just as other pthreads functions, such as pthread_create(), may not be provided as non-working stubs in conforming implementations (due to the "shall not be provided clause" which compels them to behave as defined, if provided), the same was intended to be true of functions such as pthread_attr_setscope(), for the same reason. Note that the clause on p. 5, lines 157-161 does not apply in this case as the function is always defined, whether or not the related option is. The problem is that the appearance of the ENOSYS lines in the optional thread scheduling functions creates the appearance of an ambiguity in the standard, since it seems to condone providing stubs for these functions, where the stubs return ENOSYS. One view is that the text as written prohibits this interpretation. This is because the "Otherwise" clauses in lines such as p. 302, lines 558-562, which read as "Otherwise: Either the implementation shall support the ... functions as described above or the ... functions shall not be provided". prohibit such stubs since such implementations would fail to "support the ... functions as described above", therefore the standard mandates that they "shall not be provided". In this view, both behaviors (a) and (b) for question two would be permitted in conforming implementations, but not (c). Since in this view, ENOSYS can not occur, the lines which begin with "If any of the following conditions occur" are inoperative and should be removed from the standard as a clarifying editorial correction. However, others hold that the inclusion of lines such as p. 302, lines 575-580 creates the impression that stubs returning ENOSYS are permitted for these functions. And in fact, several implementations have chosen to interpret the standard in this manner. It is for this reason that we hold that the standard is ambiguous in this respect for those functions, such as pthread_attr_setscope(), which do provide the "If occurs" ENOSYS error code description. Thus, no conformance distinction can be made between behaviors (a), (b), and (c) for these functions. Finally, note that for functions, such as pthread_create(), where the ENOSYS text was not included no such ambiguity exists. For these functions, only behaviors (a) (provide no version of the function) or (b) (provide a completely working function of the function) are permitted for conforming implementations. Behavior (c) (provide a stub returning ENOSYS) is unambiguously ruled out. Forwarded to Interpretations group: Dec 11 1996 Proposed resolution circulated: Mar 12 1998 Finalised: March 30 1998 ----- Andrew Josey PASC Functional Chair Interpretations The Open Group Apex Plaza,Forbury Road, Reading,Berks.RG1 1AX,England Tel: +44 118 9508311 ext 2250 Fax: +44 118 9500110 Email: a.josey@opengroup.org