Use of the information contained in this unapproved document is at your own risk.

Last update: 30 March,1998

								1003.1c-95  #43

 _____________________________________________________________________________

	Interpretation Number:	XXXX
        Topic:                  PTHREAD_PRIORITY_SCHEDULING and ENOSYS
        Relevant Sections:      13.5.1.2

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