From ajosey@rdg.opengroup.org Thu Apr 17 10:13:41 1997 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 KAA26207 for ; Thu, 17 Apr 1997 10:13:35 +0200 Received: by mailgate.rdg.opengroup.org; id AA02195; Thu, 17 Apr 1997 09:13:46 GMT Message-Id: <9704170913.AA02195@mailgate.rdg.opengroup.org> Received: by mailhome.rdg.opengroup.org (1.36.108.10/16.2) id AA01832; Thu, 17 Apr 1997 09:10:39 +0100 From: ajosey@rdg.opengroup.org (Andrew Josey) Date: Thu, 17 Apr 1997 09:10:39 +0100 In-Reply-To: Andrew Josey's message as of Apr 17, 9:04am. 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: 1003.1c-1995 Finalised PASC Interps Attached are the finalised PASC 1003.1c-1995 interpretations since October 1996. These are being circulated in accordance with Action 9610-60 . regards Andrew ----- 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 #--------------------------------CUT HERE------------------------------------- #! /bin/sh # # This is a shell archive. Save this into a file, edit it # and delete all lines above this comment. Then give this # file to sh by executing the command "sh file". The files # will be extracted into the current directory owned by # you with default permissions. # # The files contained herein are: # # -rw-r--r-- 1 ajosey other 4256 Apr 15 12:24 pasc-1003.1c-23.html # -rw-r--r-- 1 ajosey other 2887 Apr 15 12:24 pasc-1003.1c-17.html # -rw-r--r-- 1 ajosey other 2084 Apr 15 12:24 pasc-1003.1c-31.html # -rw-r--r-- 1 ajosey other 3445 Apr 15 12:24 pasc-1003.1c-30.html # -rw-r--r-- 1 ajosey other 1952 Apr 15 12:24 pasc-1003.1c-35.html # -rw-r--r-- 1 ajosey other 3085 Apr 15 12:24 pasc-1003.1c-34.html # -rw-r--r-- 1 ajosey other 2166 Apr 15 12:24 pasc-1003.1c-38.html # -rw-r--r-- 1 ajosey other 3567 Apr 15 12:24 pasc-1003.1c-36.html # -rw-r--r-- 1 ajosey other 3359 Apr 15 12:24 pasc-1003.1c-29.html # -rw-r--r-- 1 ajosey other 1913 Apr 15 12:24 pasc-1003.1c-26.html # -rw-r--r-- 1 ajosey other 1902 Apr 15 12:24 pasc-1003.1c-25.html # -rw-r--r-- 1 ajosey other 2326 Apr 15 12:24 pasc-1003.1c-40.html # -rw-r--r-- 1 ajosey other 3434 Apr 15 12:24 pasc-1003.1c-39.html # -rw-r--r-- 1 ajosey other 2504 Apr 15 12:24 pasc-1003.1c-33.html # echo 'x - pasc-1003.1c-23.html' if test -f pasc-1003.1c-23.html; then echo 'shar: not overwriting pasc-1003.1c-23.html'; else sed 's/^X//' << '________This_Is_The_END________' > pasc-1003.1c-23.html X X X[Ref: pasc-1003.1c-23] Topic: pthread_attr_setschedparam X X X

XPASC Interpretation Ref: pasc-1003.1c-23
Topic: pthread_attr_setschedparam X

X

X

XThis is an unapproved interpretation of PASC P1003.1c-1995. X

XUse of the information contained in this unapproved document is at your Xown risk. X

XLast update: 15 April,1997 X

X
X								1003.1c-95  #23
X
X _____________________________________________________________________________
X
X	Interpretation Number:	23
X	Topic:               pthread_attr_setschedparam
X	Relevant Sections:   13.5.1.2
X
XInterpretation Request:
X-----------------------
X
X
X	Date: Tue, 16 Jul 1996 16:06:07 -0700
X	From: "Scott J. Norton" <sjn@hpwssjn.cup.hp.com>
X
X
XSection: 13.5.1.2, pthread_attr_setschedparam() page 122
X
XThere is no way to validate the priority value passed. When this function is
Xcalled the implementation does not know whether the application has or will
Xbe changing the policy via pthread_schedsetpolicy(). Since it doesn't
Xhave a policy that it knows the application wants it cannot veify that
Xthe priority is indeed valid.
X
XThis is one of the reasons POSIX.1b did not provide totally separate 
Xroutines to set the policy and priority. In POSIX.1b, anytime the
Xpolicy is changed, the new priority must also be specified. It is
Xpossible to change the priority only, but the priority is changed for
Xthe policy that is in effect at the moment. There is no way to do this
Xwith POSIX.1c thread attributes.
X
XThe priority specified in pthread_attr_setschedparam() can only be
Xvalidated if one of two things are done:
X
X	a) a sched_param is also passed to pthread_attr_setschedpolicy() so
X	   that attributes act the same way as ALL other scheduling functions.
X
X		or
X
X	b) it is mandated that the priority specified in 
X	   pthread_attr_setschedparam() must be a valid priority for the
X	   scheduling policy currently in the "schedpolicy" attribute of
X	   the specified attributes. This will force the applications to
X	   always set the policy first and allow the implementation to
X	   provide error checking on the priority.
X
XHow is an implementation supposed to provide correct error checking on
Xthe sched_param structure passed to pthread_attr_setschedparam()?
X
XA similar problem exists with pthread_attr_setscope(). Most implementations
Xwill allow applications to use SCHED_FIFO and SCHED_RR for threads of
XPTHREAD_SCOPE_PROCESS but not for threads of PTHREAD_SCOPE_SYSTEM.
XHowever, unless it is specified that the permission checking for the
Xscheduling policy and priority are done according to the scope attributes
Xcurrently set, an implementation cannot perform proper permission checking
Xon the policy and priority.
X
XFor example: an application may call pthread_attr_setschedpolicy() to
Xchange the policy to SCHED_FIFO while the scope attribute is currently
Xset to PTHREAD_SCOPE_SYSTEM. The next statement may be a call to
Xpthread_attr_setscope() to change the scope to PTHREAD_SCOPE_PROCESS.
XThis ordering of code is currently allowed by POSIX.1c and thus
Xan implementation cannot do proper permission checking of scheduling
Xvalues.
X
XShould the description of the schedpolicy and schedparam attributes state
Xthat they check permissions based on the current settings of the
Xcontentionscope and schedpolicy attributes in the attribute structure?
XThis will force applications to make these calls in a predefined order
Xsuch that an implementation can provide proper error checking.
X
X
X
XInterpretation response
X-----------------------
XThe standard is clear that setting the scheduling policy or priority 
Xvalues in the scheduling attribute object does not actually change 
Xthe value for any threads.  It is only when the attribute object is 
Xused in a pthread_create that the parameters are used and it is at 
Xthat time that the parameters shall be consistent.  The scheduling 
Xpolicy and priorities of an existing thread may be changed using the 
Xpthread_setschedparm function which requires both a policy and a 
Xpriority.
X
XRationale
X---------
XNone
X
XForwarded to Interpretations group: July 17th 1996
XFinalised April 14 1997
X
X
X ________This_Is_The_END________ if test `wc -l < pasc-1003.1c-23.html` -ne 111; then echo 'shar: pasc-1003.1c-23.html was damaged during transit (should have been 111 bytes)' fi fi ; : end of overwriting check echo 'x - pasc-1003.1c-17.html' if test -f pasc-1003.1c-17.html; then echo 'shar: not overwriting pasc-1003.1c-17.html'; else sed 's/^X//' << '________This_Is_The_END________' > pasc-1003.1c-17.html X X X[Ref: pasc-1003.1c-17] Topic: pthread_attr_setschedparam X X X

XPASC Interpretation Ref: pasc-1003.1c-17
Topic: pthread_attr_setschedparam X

X

X

XThis is an unapproved interpretation of PASC P1003.1c-1995. X

XUse of the information contained in this unapproved document is at your Xown risk. X

XLast update: 15 April,1997 X

X
X								1003.1c-95  #17
X
X _____________________________________________________________________________
X
X	Interpretation Number:	17
X	Topic:               pthread_attr_setschedparam
X	Relevant Clauses:   13.5.1.2
X
XInterpretation Request:
X-----------------------
X
X
X	Date: Tue, 16 Jul 1996 16:06:09 -0700
X	From: "Scott J. Norton" <sjn@hpwssjn.cup.hp.com>
X
X3) Section: 13.5.1.2, pthread_attr_setschedparam()  page 122
X		      pthread_attr_setschedpolicy() page 122
X
XThese functions do not provide for an EPERM error condition. All other
Xscheduling functions have an EPERM to signify that the user doesn't have
Xpermission to set these particular scheduling attributes.
X
XSimilarly, pthread_create() also does not contain an EPERM. This behavior
Xrequires implementations to let anyone use the SCHED_FIFO/SCHED_RR policies
Xand priorities, even though all other functions trying to use them may
Xreturn EPERM.
X
XWhat is the correct behavior? Are there supposed to be EPERM error returns
Xfor these functions? Should there be an error of EPERM for pthread_create()
Xinstead? Should all three functions have an EPERM error return?
X
X
X
X
XInterpretation Response
X-----------------------
X
XThe standard is clear that setting the scheduling policy or priority 
Xvalues in the scheduling attribute object does not actually change the 
Xvalue for any threads.  It is only when the attribute object is used in 
Xa pthread_create that the parameters are used and it is at that time 
Xthat the parameters shall be consistent.  The scheduling policy and 
Xpriorities of an existing thread may be changed using the 
Xpthread_setschedparm function which requires both a policy and a 
Xpriority.
X
XThe standard is silent on what permissions, if any, an application must 
Xhave to perform a pthread_create.  Conforming implementations are free 
Xto not restrict access or to restrict access and return EPERM if 
Xdetected. Conforming applications must handle this case.
X
XRationale
X---------
X
XIt is not possible to detect or report EPERM error conditions when 
Xmodifying the scheduling parameter attributes. The intent was that 
Xattributes objects may be thought of as user data structures, and the 
Xvarious set and get functions might be nothing more than macros that 
Xassign (or read) data to or from members of that structure. 
X
XForwarded to Interpretations group: July 17th 1996
XFinalised: 14 April 1997
X
X ________This_Is_The_END________ if test `wc -l < pasc-1003.1c-17.html` -ne 82; then echo 'shar: pasc-1003.1c-17.html was damaged during transit (should have been 82 bytes)' fi fi ; : end of overwriting check echo 'x - pasc-1003.1c-31.html' if test -f pasc-1003.1c-31.html; then echo 'shar: not overwriting pasc-1003.1c-31.html'; else sed 's/^X//' << '________This_Is_The_END________' > pasc-1003.1c-31.html X X X[Ref: pasc-1003.1c-31] Topic: Dynamic Thread Scheduling Parameters Access, Description X X X

XPASC Interpretation Ref: pasc-1003.1c-31
Topic: Dynamic Thread Scheduling Parameters Access, Description X

X

X

XThis is an unapproved interpretation of PASC P1003.1c-1995. X

XUse of the information contained in this unapproved document is at your Xown risk. X

XLast update: 15 April,1997 X

X
X								1003.1c-95  #31
X
X _____________________________________________________________________________
X
X	Interpretation Number:	XXXX
X	Topic:               Dynamic Thread Scheduling Parameters Access, Description
X	Relevant Sections:   13.5.2.2
X
XInterpretation Request:
X-----------------------
X
X	Date: Tue, 27 Aug 1996 15:27:10 -0400
X	From: Dave Butenhof <butenhof@zko.dec.com>
X        Standard: 9945-1:1996 (1003.1, 1996 Edition)
X
X
X5. Section 13.5.2.2, Dynamic Thread Scheduling Parameters Access, Description
X
X   The pthread_getschedparam and pthread_setschedparam functions are
X   specified to be available only if {_POSIX_THREAD_PRIORITY_SCHEDULING};
X   this is a problem related to the previous issue with Section
X   13.5.1. According to the intent of the working group, these functions
X   should be available if {_POSIX_THREADS}. (However, if the resolution of
X   the previous issue is to make all scheduling functions available only if
X   {_POSIX_THREAD_PRIORITY_SCHEDULING}, then this section is correct
X   as-is.)
X
X        REF:    pages 300-301, section 13.5.1.2, lines 509, 552
X                page 303, section 13.5.2.2, line 599
X                page 548, section B.13.1, lines 7897-7901
X
X
XInterpretation response
X------------------------
X
XThis was an informational note only, related to interpretation request #30.
XNo interpretation was requested.
X                                   
X
XRationale
X-------------
XNone.
XForwarded to Interpretations group: August 29 1996
XFinalised: Mar 27 1997
X
X ________This_Is_The_END________ if test `wc -l < pasc-1003.1c-31.html` -ne 64; then echo 'shar: pasc-1003.1c-31.html was damaged during transit (should have been 64 bytes)' fi fi ; : end of overwriting check echo 'x - pasc-1003.1c-30.html' if test -f pasc-1003.1c-30.html; then echo 'shar: not overwriting pasc-1003.1c-30.html'; else sed 's/^X//' << '________This_Is_The_END________' > pasc-1003.1c-30.html X X X[Ref: pasc-1003.1c-30] Topic: Thread Scheduling Functions, Description X X X

XPASC Interpretation Ref: pasc-1003.1c-30
Topic: Thread Scheduling Functions, Description X

X

X

XThis is an unapproved interpretation of PASC P1003.1c-1995. X

XUse of the information contained in this unapproved document is at your Xown risk. X

XLast update: 15 April,1997 X

X
X								1003.1c-95  #30
X
X _____________________________________________________________________________
X
X	Interpretation Number:	30
X	Topic:               Thread Scheduling Functions, Description
X	Relevant Sections:   13.5.1.2 
X
XInterpretation Request:
X-----------------------
X
X	Date: Tue, 27 Aug 1996 15:27:10 -0400
X	From: Dave Butenhof <butenhof@zko.dec.com>
X        Standard: 9945-1:1996 (1003.1, 1996 Edition)
X
X
X4. Section 13.5.1.2, Thread Scheduling Functions, Description
X
X   The standard currently requires that the pthread_attr_setschedparam and
X   pthread_attr_getschedparam functions be present if {_POSIX_THREADS} is
X   defined, while all other thread scheduling attribute functions are
X   present if {_POSIX_THREAD_PRIORITY_SCHEDULING} is defined. It is
X   pointless to have pthread_attr_setschedparam without also having
X   pthread_attr_setpolicy and pthread_attr_setinheritsched, for
X   example. The rationale for this section (B.13.1) makes clear the
X   original intent of the working group -- "In this standard, the basic
X   thread scheduling functions are defined under the {_POSIX_THREADS}
X   option so that they are required of all threads
X   implementations. However, there are no specific scheduling policies
X   required by this option to allow for conforming thread implementations
X   that are not targeted to realtime applications."
X
X   Although it is understood that rationale (however clearly following the
X   intent of the working group) is not normative or binding, it is not
X   reasonable that all thread implementations support "scheduling
X   parameters" but not scheduling policy, or the other mechanism that gives
X   scheduling parameters meaning. The standard must be repaired to, at
X   least, restore consistency. While the best policy would be to follow the
X   intent of the working group, and make all of the scheduling-related
X   functions available if {_POSIX_THREADS}, it would be acceptable to make
X   them all available only if {_POSIX_THREAD_PRIORITY_SCHEDULING}.
X
X        REF:    pages 300-301, section 13.5.1.2, lines 509, 552
X                page 303, section 13.5.2.2, line 599
X                page 548, section B.13.1, lines 7897-7901
X
X
XInterpretation response
X------------------------
X
X
XThe standard is clear that on p. 300, line 509,
X_POSIX_THREAD_PRIORITY_SCHEDULING} is defined then
Xthe functions:
X    pthread_attr_setscope(), pthread_attr_getscope(),
X    pthread_attr_setinheritsched(), pthread_attr_getinheritsched(),
X    pthread_attr_setschedpolicy(), pthread_attr_getschedpolicy()
Xshall be provided.
X
XIt is also clear on page 301, line 552, that if _POSIX_THREADS is
Xdefined then the functions:
X    pthread_attr_setschedparam() and pthread_attr_getschedparam()
Xshall be provided.  Conforming implementations must conform to these. 
X
XRationale
X-------------
X
XNone.
X
XForwarded to Interpretations group: August 29 1996
XFinalised : 27 Mar 1997
X
X ________This_Is_The_END________ if test `wc -l < pasc-1003.1c-30.html` -ne 91; then echo 'shar: pasc-1003.1c-30.html was damaged during transit (should have been 91 bytes)' fi fi ; : end of overwriting check echo 'x - pasc-1003.1c-35.html' if test -f pasc-1003.1c-35.html; then echo 'shar: not overwriting pasc-1003.1c-35.html'; else sed 's/^X//' << '________This_Is_The_END________' > pasc-1003.1c-35.html X X X[Ref: pasc-1003.1c-35] Topic: cancellation points X X X

XPASC Interpretation Ref: pasc-1003.1c-35
Topic: cancellation points X

X

X

XThis is an unapproved interpretation of PASC P1003.1c-1995. X

XUse of the information contained in this unapproved document is at your Xown risk. X

XLast update: 15 April,1997 X

X
X								1003.1c-95  #35
X
X _____________________________________________________________________________
X
X	Interpretation Number:	XXXX
X	Topic:               cancellation points
X	Relevant Sections:   18.1.2
X
XInterpretation Request:
X-----------------------
X
X	Date: Tue, 03 Sep 1996 10:45:12 -0400
X	From: Dave Butenhof <butenhof@zko.dec.com>
X
X
X2. Section 18.1.2, Cancellation Points
X
X   In the second list ("A cancellation point may also occur"), several
X   functions from ISO/ANSI C 1990 are omitted, specifically (at least),
X   vprintf and vfprintf. Because printf is present, these should be
X   also. (This is critical, since the standard specifically prohibits
X   additional cancellation points for functions in POSIX.1 or ISO C.)
X
X	REF: page 348, section 18.1.2, line 65
X
XInterpretation response
X------------------------
X
XThe standard is clear that vprintf and vfprintf shall not be cancellation
Xpoints.  Conforming implementations must conform to this.  However, it
Xit the opinion of the interpretations committee that this is an oversight
Xon the part of the working and balloting groups and that they may be
Xa cancellation point.  This is being referred to the sponsor for consideration.
X          
X
XRationale
X-------------
XPrintf may be a cancellation point and it is inconsistent to not also allow
Xvprintf and vfprintf. 
X
XForwarded to Interpretations group: Sep 8 1996
XProposed resolution: 17 Jan 1997
XFinalised resolution: 18 Mar 1997
X
X
X ________This_Is_The_END________ if test `wc -l < pasc-1003.1c-35.html` -ne 64; then echo 'shar: pasc-1003.1c-35.html was damaged during transit (should have been 64 bytes)' fi fi ; : end of overwriting check echo 'x - pasc-1003.1c-34.html' if test -f pasc-1003.1c-34.html; then echo 'shar: not overwriting pasc-1003.1c-34.html'; else sed 's/^X//' << '________This_Is_The_END________' > pasc-1003.1c-34.html X X X[Ref: pasc-1003.1c-34] Topic: pthread_mutex_init, pthread_cond_init X X X

XPASC Interpretation Ref: pasc-1003.1c-34
Topic: pthread_mutex_init, pthread_cond_init X

X

X

XThis is an unapproved interpretation of PASC P1003.1c-1995. X

XUse of the information contained in this unapproved document is at your Xown risk. X

XLast update: 15 April,1997 X

X
X								1003.1c-95  #34
X
X _____________________________________________________________________________
X
X	Interpretation Number:	XXXX
X	Topic:               pthread_mutex_init, pthread_cond_init
X	Relevant Sections:   11.3.2.2.
X
XInterpretation Request:
X-----------------------
X
X	Date: Tue, 03 Sep 1996 10:45:12 -0400
X	From: Dave Butenhof <butenhof@zko.dec.com>
X
X1. Section 11.3.2.2 & 11.4.2.2
X
X   The POSIX synchronization functions in section 11 were intended to
X   allow use of efficient hardware-based synchronization mechanisms, and
X   thus, it is essential that calling code adhere to certain rules. One
X   important rule is that code cannot COPY synchronization objects, as
X   the copy may not behave the same as the original. The description of
X   Semaphore initialization specifically states that "Only sem itself
X   may be used for performning synchronization. The result of referring
X   to copies of sem in calls to sem_wait, sem_trywait, sem_post, and
X   sem_destroy, is undefined."
X
X   I believe that the intent of the working group would be best served
X   if a similar restriction had been placed upon code using the
X   pthread_mutex_t and pthread_cond_t synchronization objects, but the
X   required wording is missing from the standard. Code that currently
X   does not violate the standard may thus fail to port to
X   implementations of the standard that the working group did not intend
X   to exclude. POSIX 1003.1n should amend the standard to require that
X   conforming applications shall not copy mutex and condition variable
X   synchronization objects, just as is currently required of code using
X   POSIX semaphores.
X
X	REF: page 242, section 11.2.1.2, Semaphore Functions Description
X	REF: page 255, section 11.3.2.2, Mutex initialization
X	REF: page 261, section 11.4.2.2, Condition variable initialization
X
X
XInterpretation response
X------------------------
XThe standard is clear that it does not restrict the copying of mutex objects and
Xconforming implementations must allow copies.  However, the interpretations
Xcommittee believes that this is not the intent of the working and balloting
Xgroups.  Rather, the intent was to be the same as for semaphores with the effect
Xof using copies being "undefined".
X                                     
X
XRationale
X-------------
XImplementations may wish to use hardware support to accelerate the 
Xperformance of the mutex. For this to work, only the 'initial' copy would 
Xbe the hardware and thus shared.
X
XForwarded to Interpretations group: Sep 8 1996
XFinalised: Mar 18 1997
X
X ________This_Is_The_END________ if test `wc -l < pasc-1003.1c-34.html` -ne 79; then echo 'shar: pasc-1003.1c-34.html was damaged during transit (should have been 79 bytes)' fi fi ; : end of overwriting check echo 'x - pasc-1003.1c-38.html' if test -f pasc-1003.1c-38.html; then echo 'shar: not overwriting pasc-1003.1c-38.html'; else sed 's/^X//' << '________This_Is_The_END________' > pasc-1003.1c-38.html X X X[Ref: pasc-1003.1c-38] Topic: mutex X X X

XPASC Interpretation Ref: pasc-1003.1c-38
Topic: mutex X

X

X

XThis is an unapproved interpretation of PASC P1003.1c-1995. X

XUse of the information contained in this unapproved document is at your Xown risk. X

XLast update: 15 April,1997 X

X
X								1003.1c-95  #38
X
X _____________________________________________________________________________
X
X	Interpretation Number:	XXXX
X	Topic:               mutex
X	Relevant Sections:   2.2.2.68
X
XInterpretation Request:
X-----------------------
X
X	From: Andrew Josey (on behalf of the X/Open Base working group)
X
XPart 1. Interpretation Request for:
X   IEEE Std 1003.1c-1995 as contained in:
X   ISO/IEC 9945-1:1996(E), ANSI/IEEE Std. 1003.1, 1996 Edition.
X   Subsection 2.2.2.68, Page 20, Line 308.
X
XQuestion:
XWhy does a mutex only allow multiple threads to serialize their access to
X"shared data"? A mutex may be used to provide mutual exclusion among threads
Xtrying to access any sort of shared resource. For example, several threads
Xmay occasionally need to utilize a single hardware co-processor, and may
Xserialize access to that resource with a mutex even though it isn't "shared
Xdata".
X
XSuggested Correction:
XChange the phrase "shared data" to "shared resources".
X
XInterpretation response
X------------------------
XThe part of the definition cited is informative in scope and does not
Xrequire any restrictions on conforming applications.  The proposed
Xchange may add some additional clarity and will be referred to the
Xsponsor for consideration.  
X
X
XRationale
X-------------
XThe wording of the particular sentence is neither binding upon the
Xapplication, nor is it constrained by the interface, and it is not
Xtestable by a conformance test.  Changing 'data' to 'resources' may help
Xsomeone inexperienced in this area but does not seem to make a
Xsignificant improvement in the standard. 
X
XForwarded to Interpretations group: Dec 9 1996
XProposed resolution: Jan 29 1997
XFinalised: Feb 20 1997
X
X ________This_Is_The_END________ if test `wc -l < pasc-1003.1c-38.html` -ne 68; then echo 'shar: pasc-1003.1c-38.html was damaged during transit (should have been 68 bytes)' fi fi ; : end of overwriting check echo 'x - pasc-1003.1c-36.html' if test -f pasc-1003.1c-36.html; then echo 'shar: not overwriting pasc-1003.1c-36.html'; else sed 's/^X//' << '________This_Is_The_END________' > pasc-1003.1c-36.html X X X[Ref: pasc-1003.1c-36] Topic: primitive system data types X X X

XPASC Interpretation Ref: pasc-1003.1c-36
Topic: primitive system data types X

X

X

XThis is an unapproved interpretation of PASC P1003.1c-1995. X

XUse of the information contained in this unapproved document is at your Xown risk. X

XLast update: 15 April,1997 X

X
X								1003.1c-95  #36
X
X _____________________________________________________________________________
X
X	Interpretation Number:	XXXX
X	Topic:               primitive system data types
X	Relevant Sections:   2.5
X
XInterpretation Request:
X-----------------------
X
X
X	Date: Mon, 07 Oct 1996 14:41:09 -0400
X	From: Dave Butenhof (butenhof@zko.dec.com)
X
X1. Section 2.5, Primitive System Data Types
X
X   The pthread data types (pthread_t, pthread_attr_t, pthread_cond_t,
X   pthread_condattr_t, pthread_mutex_t, pthread_mutexattr_t,
X   pthread_key_t, pthread_once_t) are listed in this section, and in
X   Table 2-1. Unfortunately, while all of these types have been
X   specifically described as "opaque" types (and 2.5 even reminds
X   readers that there are "no defined comparison or assignment
X   operators" for most of the types, oddly omitting some), The second
X   paragraph of this section says clearly "All of the types listed in
X   Table 2-1 shall be arithmetic types".
X
X1a)   This is not true, and the working group did not intend to make this
X   a requirement. Either the statement should be changed, for example,
X   to list the specific types that must be arithmetic, or to exclude
X   all of those that needn't be -- or else the non arithmetic types
X   (all the pthread types) should be moved to a separate table.
X
X1b)   In addition, the list of types for which there are no defined
X   comparison or assignment operators omits pthread_key_t and
X   pthread_once_t, both of which are also "opaque types", and have no
X   comparison or assignment operators.
X
X
XInterpretation response
X-----------------------
X
XThe standard is unclear on this issue, and no conformance distinction
Xcan be made between alternative implementations based on this.
XThis is being referred to the sponsor. 
X
XRationale
X-------------
X
XAs noted in the request these types are described elsewhere in the
Xstandard as opaque types as an aid to extensibility. Although not
Xpart of the normative text, the rationale for POSIX 1003.1c/D10
Xmakes it very clear that these are opaque data types.
X
XFurthermore, the text in lines 970-972 that "There are no defined
Xcomparison or assignment operators for the types pthread_attr_t,
Xpthread_cond_t, pthread_condattr_t, pthread_mutex_t, and
Xpthread_mutex_attr_t." contradicts the claim on line 963 that these
Xtypes shall be arithmetic, since all arithmetic types have defined
Xcomparison and assignment operators.  
X
XThe interpretations committee recommends to the sponsor that the
Xfollowing changes be made:           
X
XProposed changes to 1003.1 (not part of this interpretation).
X--------------------------
X
XChange 1003.1-1996 ll 963 first sentence from
X"All of the types listed in Table 2-1 shall be arithmetic types;"
XTo:
X"All of the types listed in Table 2-1 shall be arithmetic types,
Xexcept the types pthread_t, pthread_attr_t, pthread_mutex_t,
Xpthread_mutexattr_t, pthread_cond_t, pthread_condattr_t, pthread_key_t,
Xpthread_once_t;"
X
XForwarded to Interpretations group: Oct 20 1996
XProposed interpretation:29 Jan 97
XFinalised: Feb 18 1997
X
X ________This_Is_The_END________ if test `wc -l < pasc-1003.1c-36.html` -ne 98; then echo 'shar: pasc-1003.1c-36.html was damaged during transit (should have been 98 bytes)' fi fi ; : end of overwriting check echo 'x - pasc-1003.1c-29.html' if test -f pasc-1003.1c-29.html; then echo 'shar: not overwriting pasc-1003.1c-29.html'; else sed 's/^X//' << '________This_Is_The_END________' > pasc-1003.1c-29.html X X X[Ref: pasc-1003.1c-29] Topic: Get scheduling parameter limits X X X

XPASC Interpretation Ref: pasc-1003.1c-29
Topic: Get scheduling parameter limits X

X

X

XThis is an unapproved interpretation of PASC P1003.1c-1995. X

XUse of the information contained in this unapproved document is at your Xown risk. X

XLast update: 15 April,1997 X

X
X								1003.1c-95  #29
X
X _____________________________________________________________________________
X
X	Interpretation Number:	XXXX
X	Topic:               Get scheduling parameter limits
X	Relevant Sections:   13.3.6
X
XInterpretation Request:
X-----------------------
X
X	Date: Tue, 27 Aug 1996 15:27:10 -0400
X	From: Dave Butenhof <butenhof@zko.dec.com>
X        Standard: 9945-1:1996 (1003.1, 1996 Edition)
X
X
X3. Section 13.3.6, Get Scheduling Parameter Limits
X
X   The standard fails to formalize the dependency of
X   _POSIX_THREAD_PRIORITY_SCHEDULING on _POSIX_PRIORITY_SCHEDULING. That
X   is, a conforming implementation could choose to support the latter but
X   not the former. That was intentional, BUT, there really is a "hidden"
X   dependency... to use thread priority scheduling one must call
X   sched_priority_get_min() and/or sched_priority_get_max() to determine
X   the legal priority range for any policy. And those functions are
X   required only under _POSIX_PRIORITY_SCHEDULING, and therefore might not
X   exist. I would suggest one of three solutions:
X
X   1) require _POSIX_PRIORITY_SCHEDULING if the implementation supports
X      _POSIX_THREAD_PRIORITY_SCHEDULING, or,
X   2) sched_priority_get_min/_max must be required if EITHER option is
X      supported, or,
X   3) go back to the wording in one of the earlier drafts, where there was
X      no separate thread priority scheduling option at all -- the thread
X      scheduling functions were present IFF the system supported threads 
X      and priority scheduling.
X
X   Option 2 is likely to be the least contentious of the three, and it's
X   certainly sufficient.
X
X        REF:    pages 53-54, section 2.9.3, lines 1602-1667
X                page 296, section 13.3.6.1, lines 340-341
X
X
XInterpretation response
X------------------------
XThe standard is clear in section 13.2 that priorities shall be in the
Xrange defined for the policy and in section 13.3.6 it only requires the
Xsched_get_priority_max and sched_get_priority_min function if
X_POSIX_PRIORITY_SCHEDULING is defined.  The standard's conformance
Xrequirement upon these functions when that option is not defined is only
Xthat if the functions are provided, they shall be provided as specified
Xor they shall fail.  The standard is also clear that the
X_POSIX_THREAD_PRIORITY_SCHEDULING option does not require that the
Xsched_get_priority_max and sched_get_priority_min functions be defined.
XThe interpretations committee believes that not requiring the definition
Xof these functions may make the _POSIX_THREAD_PRIORITY_SCHEDULING option
Xless useful and was not the intention of the working and balloting
Xgroups.  This is being referred to the sponsor for consideration.   
X
XRationale
X-------------
X
XNone.
X
XForwarded to Interpretations group: August 29 1996
XProposed resolution: 29 Jan 97
XFinalised: Feb 14 1997
X
X ________This_Is_The_END________ if test `wc -l < pasc-1003.1c-29.html` -ne 88; then echo 'shar: pasc-1003.1c-29.html was damaged during transit (should have been 88 bytes)' fi fi ; : end of overwriting check echo 'x - pasc-1003.1c-26.html' if test -f pasc-1003.1c-26.html; then echo 'shar: not overwriting pasc-1003.1c-26.html'; else sed 's/^X//' << '________This_Is_The_END________' > pasc-1003.1c-26.html X X X[Ref: pasc-1003.1c-26] Topic: tmpname() X X X

XPASC Interpretation Ref: pasc-1003.1c-26
Topic: tmpname() X

X

X

XThis is an unapproved interpretation of PASC P1003.1c-1995. X

XUse of the information contained in this unapproved document is at your Xown risk. X

XLast update: 15 April,1997 X

X
X								1003.1c-95  #26
X
X _____________________________________________________________________________
X
X	Interpretation Number:	XXXX
X	Topic:               tmpname()
X	Relevant Sections:   18.1.2
X
XInterpretation Request:
X-----------------------
X
X	Date: Mon Aug  5 10:26:16 BST 1996
X	From: Andrew Josey, 
X
X
XThere is an apparent error in ISO 9945-1:1996 which includes IEEE Std POSIX
X1003.1c-1995.
X
XSection 18.1.2 lists the "tmpname()" function on line 65.
X
XThis should be "tmpnam()" as on page 205 line 29.
X
XThis is a clear contradiction between two sections of the standard, where
Xthe normative section is correct. This should be forwarded to the sponsor, 
Xso that the IEEE errata correction process be applied.
X
XInterpretation response
X------------------------
XThe standard is clear in section 8.1 on page 205 line 63 that the C
Xlanguage function tmpnam() shall be provided in the POSIX.1 with C
XLanguage Binding.  The reference in section 18.1.2 page 348 line 65 to a
Xfunction 'tmpname()' refers to a function that is not defined anywhere
Xin the standard and thus represents a defect in the standard.  The
Xinterpretation committee believes that intent of the working and
Xballoting groups was clear and that this is typographical error. It is
Xbeing referred to the sponsor for correction.  
X
XRationale
X-------------
XNone.
X
XForwarded to Interpretations group: August 5 1996
XProposed resolution: Jan 17 1997
XFinalised: Feb 14 1997
X
X ________This_Is_The_END________ if test `wc -l < pasc-1003.1c-26.html` -ne 64; then echo 'shar: pasc-1003.1c-26.html was damaged during transit (should have been 64 bytes)' fi fi ; : end of overwriting check echo 'x - pasc-1003.1c-25.html' if test -f pasc-1003.1c-25.html; then echo 'shar: not overwriting pasc-1003.1c-25.html'; else sed 's/^X//' << '________This_Is_The_END________' > pasc-1003.1c-25.html X X X[Ref: pasc-1003.1c-25] Topic: _POSIX_THREAD_* vs _POSIX_THREADS_* X X X

XPASC Interpretation Ref: pasc-1003.1c-25
Topic: _POSIX_THREAD_* vs _POSIX_THREADS_* X

X

X

XThis is an unapproved interpretation of PASC P1003.1c-1995. X

XUse of the information contained in this unapproved document is at your Xown risk. X

XLast update: 15 April,1997 X

X
X								1003.1c-95  #25
X
X _____________________________________________________________________________
X
X	Interpretation Number:	XXXX
X	Topic:               _POSIX_THREAD_* vs _POSIX_THREADS_*
X	Relevant Sections:   2-10, F3.1
X
XInterpretation Request:
X-----------------------
X
X	Date: Thu Jul 25 10:15:49 BST 1996
X	From: Andrew Josey, 
X
X
XThere is an apparent error in ISO 9945-1:1996 which include IEEE Std POSIX
X1003.1c-1995.
X
XTable 2-10 "Compile-Time Symbolic  constants" lines 1649-1661 state 
X
X"_POSIX_THREAD_ATTR_STACKADDR" ... "_POSIX_THREAD_PROCESS_SHARED" 
X
Xyet the informative section F.3.1 lines 392-425 states 
X"_POSIX_THREADS_ATTR_STACKADDR".
X
XNote the extra "S" after "THREAD".
X
XThis is a clear contradiction between two sections of the standard, where
Xthe normative section is correct. This should be forwarded to the sponsor, 
Xso that the IEEE errata correction process be applied.
X
XInterpretation response
X------------------------
XThe standard clearly states the requirement for _POSIX_THREAD_*
Xin the normative section, and conforming implementations must conform
Xto this. The text in Annex F is informative and this will be
Xforwarded to the sponsor so that the IEEE errata correction process
Xcan be applied. 
X
XRationale
X-------------
XNone.
XForwarded to Interpretations group: July 25th 1996
XProposed interpretation: 17 Jan 1997
XFinalised: Feb 14 1997
X
X ________This_Is_The_END________ if test `wc -l < pasc-1003.1c-25.html` -ne 65; then echo 'shar: pasc-1003.1c-25.html was damaged during transit (should have been 65 bytes)' fi fi ; : end of overwriting check echo 'x - pasc-1003.1c-40.html' if test -f pasc-1003.1c-40.html; then echo 'shar: not overwriting pasc-1003.1c-40.html'; else sed 's/^X//' << '________This_Is_The_END________' > pasc-1003.1c-40.html X X X[Ref: pasc-1003.1c-40] Topic: sigsuspend X X X

XPASC Interpretation Ref: pasc-1003.1c-40
Topic: sigsuspend X

X

X

XThis is an unapproved interpretation of PASC P1003.1c-1995. X

XUse of the information contained in this unapproved document is at your Xown risk. X

XLast update: 15 April,1997 X

X
X								1003.1c-95  #40
X
X _____________________________________________________________________________
X
X	Interpretation Number:	XXXX
X	Topic:               sigsuspend
X	Relevant Sections:   3.3.7.3
X
XInterpretation Request:
X-----------------------
X
X	From: Andrew Josey (on behalf of the X/Open Base working group)
X
XInterpretation Request for:
X   IEEE Std 1003.1c-1995 as contained in:
X   ISO/IEC 9945-1:1996(E), ANSI/IEEE Std. 1003.1, 1996 Edition.
X   Subsection 3.3.7.3, Page 87, Line 1203.
X
XQuestion:
XIs the phrase "Since the sigsuspend() function suspends process execution
Xindefinitely," correct? It is clear from line 1190 that the function suspends
Xthe calling "thread", but why would the "process" be suspended indefinitely?
X
XSuggested Correction:
XChange the phrase to "Since the sigsuspend() function suspends thread execution
Xindefinitely,".
X
X
XInterpretation response
X-----------------------
XThe standard is clear that sigsuspend shall suspend the calling
Xthread until the delivery of a signal.  The explanatory subclause in
Xthe returns section is not a correct representation of what happens
Xand this is being referred to the sponsor for correction as an
Xeditorial error. 
X
X
XRationale
X-------------
XIn the the declaritive text of the description for sigsuspend(), the
Xwording is very clear that the function will suspend the thread.  The
XInterpretations Committee is believes that this is exactly what was
Xintended by the working and balloting groups.  The subclause in the
Xreturns section is clearly explanitory but does not match what the
Xdeclaritive text states and is incorrect.  During development of the
Xstandard, there were several changes made that required changing
Xprocess to thread and this was one that was missed.  
X
X
XForwarded to Interpretations group: Dec 9 1996
XProposed resolution: 29 Jan 97
XFinalised: Feb 14 1997
X
X ________This_Is_The_END________ if test `wc -l < pasc-1003.1c-40.html` -ne 72; then echo 'shar: pasc-1003.1c-40.html was damaged during transit (should have been 72 bytes)' fi fi ; : end of overwriting check echo 'x - pasc-1003.1c-39.html' if test -f pasc-1003.1c-39.html; then echo 'shar: not overwriting pasc-1003.1c-39.html'; else sed 's/^X//' << '________This_Is_The_END________' > pasc-1003.1c-39.html X X X[Ref: pasc-1003.1c-39] Topic: thread - safety X X X

XPASC Interpretation Ref: pasc-1003.1c-39
Topic: thread - safety X

X

X

XThis is an unapproved interpretation of PASC P1003.1c-1995. X

XUse of the information contained in this unapproved document is at your Xown risk. X

XLast update: 15 April,1997 X

X
X								1003.1c-95  #39
X
X _____________________________________________________________________________
X
X	Interpretation Number:	XXXX
X	Topic:               thread - safety
X	Relevant Sections:   2.3.9
X
XInterpretation Request:
X-----------------------
X
X	From: Andrew Josey (on behalf of the X/Open Base working group)
X
XPart 1. Interpretation Request for:
X   IEEE Std 1003.1c-1995 as contained in:
X   ISO/IEC 9945-1:1996(E), ANSI/IEEE Std. 1003.1, 1996 Edition.
X   Subsection 2.3.9, Page 32, Line 754-761.
X
XQuestion:
XThe referenced paragraph says that all POSIX.1 and ISO C functions except
Xthose enumerated within the paragraph shall be thread safe. Why are the
Xfunctions getenv(), localeconv(), and strerror() not in the list of exceptions?
XTheir absence implies that they SHALL be thread safe, yet their definitions
Xeach state that the object pointed to by their return value MAY be overwritten
Xby a subsequent call to the same function. If this is the case, implementations
Xcannot provide thread safety through internal synchronization because the return
Xobject as seen by one thread may be corrupted by another thread AFTER the
Xfunction returns to the first thread, but before the first thread is finished
Xutilizing or copying the object. Although it is quite possible for an
Ximplementation to provide these in a thread safe fashion using thread specific
Xdata with destructors, the function definitions allow non-thread safe behavior,
Xdirectly contradicting this paragraph. These 3 functions fall into the same
Xgeneral category as asctime() or ttyname(), and should be in this list.  In the
Xfuture, thread safe versions of these functions should be included in the
Xstandard (getenv_r, localeconv_r, strerror_r).
X
XSuggested Correction:
XAdd getenv(), localeconv(), and strerror() to the list of functions that need
Xnot be thread safe.
X
X
XInterpretation response
X------------------------
XThe standard is clear that getenv(), localeconv(), and strerror() must
Xbe thread-safe. A conforming implementations shall satisfy this
Xcondition.
X
XHowever, concerns have been raised in the interpretation committee that
Xthis was not the intent of the working and balloting groups.  This is
Xbeing referred to the sponsor consideration.     
X
X
XRationale
X-------------
XIt appears that the standard has a defect - the working group and the
Xballoting group seems to have missed these three functions. Note, that
Xthe standard states that all POSIX.1 and ISO C be functions be thread
Xsafe but for a list of exceptions that have _r equivalents. These
Xfunctions should have been part of the list of exceptions.
X
XA getenv_r() function should clearly be added.  Likewise requirements
Xfor localeconv_r() and strerror_r() should added for systems that
Xprovide localeconv() and strerror().  (Note that these ANSI C
Xfunctions are not required by IEEE Std 1003.1.) 
X
XForwarded to Interpretations group: Dec 9 1996
XProposed resolution: Jan 17 1997
XFinalised: Feb 14 1997
X
X ________This_Is_The_END________ if test `wc -l < pasc-1003.1c-39.html` -ne 88; then echo 'shar: pasc-1003.1c-39.html was damaged during transit (should have been 88 bytes)' fi fi ; : end of overwriting check echo 'x - pasc-1003.1c-33.html' if test -f pasc-1003.1c-33.html; then echo 'shar: not overwriting pasc-1003.1c-33.html'; else sed 's/^X//' << '________This_Is_The_END________' > pasc-1003.1c-33.html X X X[Ref: pasc-1003.1c-33] Topic: Thread Cancellation, Async-Cancel Safety X X X

XPASC Interpretation Ref: pasc-1003.1c-33
Topic: Thread Cancellation, Async-Cancel Safety X

X

X

XThis is an unapproved interpretation of PASC P1003.1c-1995. X

XUse of the information contained in this unapproved document is at your Xown risk. X

XLast update: 15 April,1997 X

X
X								1003.1c-95  #33
X
X _____________________________________________________________________________
X
XInterpretation Number:	33
XTopic:               Thread Cancellation, Async-Cancel Safety
XRelevant Sections:   18.1.4
X
XInterpretation Request:
X-----------------------
X
X	Date: Tue, 27 Aug 1996 15:27:10 -0400
X	From: Dave Butenhof <butenhof@zko.dec.com>
X        Standard: 9945-1:1996 (1003.1, 1996 Edition)
X
X
X7. Section 18.1.4, Thread Cancellation, Async-Cancel Safety
X
X   pthread_cancel is specified to be async-cancel safe, along with the
X   pthread_setcancelstate and pthread_setcanceltype functions. I see
X   no reasonable justification for allowing cancellation while async
X   cancellation is enabled, nor does the rationale attempt to give any
X   justification. I believe that pthread_cancel should be removed from
X   the list of async-cancel safe functions. Async cancellation is an
X   unusual "aberration", and I see no reason to allow use of any POSIX
X   standard functions with async cancellation type except the
X   functions required to disable cancellation.
X
X        REF:    page 349, section 18.1.4, line 112
X
X
X
XInterpretation for IEEE Std 1003.1c-1995:
X-------------------------------------------
X
XThe standard is clear that pthread_cancel shall be async-cancel safe, and
Xconforming implementations must conform to this.  
X
XRationale
X-------------
XRequiring pthread_cancel() to be async-cancel safe potentially makes
Xit easier for helper threads running with asynchronous cancellation
Xenabled to themselves cancel other threads.  This imposes no undue
Xburden on implementations since, if necessary, the pthread_cancel()
Ximplementation can always internally set the cancellation state to
Xdefer cancellation while pthread_cancel() is being executed and then
Xrestore the cancellation state after the cancel request has been
Xexecuted.   
X
XForwarded to Interpretations group: August 29 1996
XProposed resolution: 18 Sep 96
XFinalised: 27 Jan 97
X
X ________This_Is_The_END________ if test `wc -l < pasc-1003.1c-33.html` -ne 72; then echo 'shar: pasc-1003.1c-33.html was damaged during transit (should have been 72 bytes)' fi fi ; : end of overwriting check exit 0