PASC Interpretation Ref: pasc-1003.1c-17
Topic: pthread_attr_setschedparam

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

Last update: 15 April,1997

								1003.1c-95  #17

 _____________________________________________________________________________

	Interpretation Number:	17
	Topic:               pthread_attr_setschedparam
	Relevant Clauses:   13.5.1.2

Interpretation Request:
-----------------------


	Date: Tue, 16 Jul 1996 16:06:09 -0700
	From: "Scott J. Norton" <sjn@hpwssjn.cup.hp.com>

3) Section: 13.5.1.2, pthread_attr_setschedparam()  page 122
		      pthread_attr_setschedpolicy() page 122

These functions do not provide for an EPERM error condition. All other
scheduling functions have an EPERM to signify that the user doesn't have
permission to set these particular scheduling attributes.

Similarly, pthread_create() also does not contain an EPERM. This behavior
requires implementations to let anyone use the SCHED_FIFO/SCHED_RR policies
and priorities, even though all other functions trying to use them may
return EPERM.

What is the correct behavior? Are there supposed to be EPERM error returns
for these functions? Should there be an error of EPERM for pthread_create()
instead? Should all three functions have an EPERM error return?




Interpretation Response
-----------------------

The standard is clear that setting the scheduling policy or priority 
values in the scheduling attribute object does not actually change the 
value for any threads.  It is only when the attribute object is used in 
a pthread_create that the parameters are used and it is at that time 
that the parameters shall be consistent.  The scheduling policy and 
priorities of an existing thread may be changed using the 
pthread_setschedparm function which requires both a policy and a 
priority.

The standard is silent on what permissions, if any, an application must 
have to perform a pthread_create.  Conforming implementations are free 
to not restrict access or to restrict access and return EPERM if 
detected. Conforming applications must handle this case.

Rationale
---------

It is not possible to detect or report EPERM error conditions when 
modifying the scheduling parameter attributes. The intent was that 
attributes objects may be thought of as user data structures, and the 
various set and get functions might be nothing more than macros that 
assign (or read) data to or from members of that structure. 

Forwarded to Interpretations group: July 17th 1996
Finalised: 14 April 1997

PASC Interpretation Ref: pasc-1003.1c-23
Topic: pthread_attr_setschedparam

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

Last update: 15 April,1997

								1003.1c-95  #23

 _____________________________________________________________________________

	Interpretation Number:	23
	Topic:               pthread_attr_setschedparam
	Relevant Sections:   13.5.1.2

Interpretation Request:
-----------------------


	Date: Tue, 16 Jul 1996 16:06:07 -0700
	From: "Scott J. Norton" <sjn@hpwssjn.cup.hp.com>


Section: 13.5.1.2, pthread_attr_setschedparam() page 122

There is no way to validate the priority value passed. When this function is
called the implementation does not know whether the application has or will
be changing the policy via pthread_schedsetpolicy(). Since it doesn't
have a policy that it knows the application wants it cannot veify that
the priority is indeed valid.

This is one of the reasons POSIX.1b did not provide totally separate 
routines to set the policy and priority. In POSIX.1b, anytime the
policy is changed, the new priority must also be specified. It is
possible to change the priority only, but the priority is changed for
the policy that is in effect at the moment. There is no way to do this
with POSIX.1c thread attributes.

The priority specified in pthread_attr_setschedparam() can only be
validated if one of two things are done:

	a) a sched_param is also passed to pthread_attr_setschedpolicy() so
	   that attributes act the same way as ALL other scheduling functions.

		or

	b) it is mandated that the priority specified in 
	   pthread_attr_setschedparam() must be a valid priority for the
	   scheduling policy currently in the "schedpolicy" attribute of
	   the specified attributes. This will force the applications to
	   always set the policy first and allow the implementation to
	   provide error checking on the priority.

How is an implementation supposed to provide correct error checking on
the sched_param structure passed to pthread_attr_setschedparam()?

A similar problem exists with pthread_attr_setscope(). Most implementations
will allow applications to use SCHED_FIFO and SCHED_RR for threads of
PTHREAD_SCOPE_PROCESS but not for threads of PTHREAD_SCOPE_SYSTEM.
However, unless it is specified that the permission checking for the
scheduling policy and priority are done according to the scope attributes
currently set, an implementation cannot perform proper permission checking
on the policy and priority.

For example: an application may call pthread_attr_setschedpolicy() to
change the policy to SCHED_FIFO while the scope attribute is currently
set to PTHREAD_SCOPE_SYSTEM. The next statement may be a call to
pthread_attr_setscope() to change the scope to PTHREAD_SCOPE_PROCESS.
This ordering of code is currently allowed by POSIX.1c and thus
an implementation cannot do proper permission checking of scheduling
values.

Should the description of the schedpolicy and schedparam attributes state
that they check permissions based on the current settings of the
contentionscope and schedpolicy attributes in the attribute structure?
This will force applications to make these calls in a predefined order
such that an implementation can provide proper error checking.



Interpretation response
-----------------------
The standard is clear that setting the scheduling policy or priority 
values in the scheduling attribute object does not actually change 
the value for any threads.  It is only when the attribute object is 
used in a pthread_create that the parameters are used and it is at 
that time that the parameters shall be consistent.  The scheduling 
policy and priorities of an existing thread may be changed using the 
pthread_setschedparm function which requires both a policy and a 
priority.

Rationale
---------
None

Forwarded to Interpretations group: July 17th 1996
Finalised April 14 1997

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

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

Last update: 15 April,1997

								1003.1c-95  #25

 _____________________________________________________________________________

	Interpretation Number:	XXXX
	Topic:               _POSIX_THREAD_* vs _POSIX_THREADS_*
	Relevant Sections:   2-10, F3.1

Interpretation Request:
-----------------------

	Date: Thu Jul 25 10:15:49 BST 1996
	From: Andrew Josey, 


There is an apparent error in ISO 9945-1:1996 which include IEEE Std POSIX
1003.1c-1995.

Table 2-10 "Compile-Time Symbolic  constants" lines 1649-1661 state 

"_POSIX_THREAD_ATTR_STACKADDR" ... "_POSIX_THREAD_PROCESS_SHARED" 

yet the informative section F.3.1 lines 392-425 states 
"_POSIX_THREADS_ATTR_STACKADDR".

Note the extra "S" after "THREAD".

This is a clear contradiction between two sections of the standard, where
the normative section is correct. This should be forwarded to the sponsor, 
so that the IEEE errata correction process be applied.

Interpretation response
------------------------
The standard clearly states the requirement for _POSIX_THREAD_*
in the normative section, and conforming implementations must conform
to this. The text in Annex F is informative and this will be
forwarded to the sponsor so that the IEEE errata correction process
can be applied. 

Rationale
-------------
None.
Forwarded to Interpretations group: July 25th 1996
Proposed interpretation: 17 Jan 1997
Finalised: Feb 14 1997

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

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

Last update: 15 April,1997

								1003.1c-95  #26

 _____________________________________________________________________________

	Interpretation Number:	XXXX
	Topic:               tmpname()
	Relevant Sections:   18.1.2

Interpretation Request:
-----------------------

	Date: Mon Aug  5 10:26:16 BST 1996
	From: Andrew Josey, 


There is an apparent error in ISO 9945-1:1996 which includes IEEE Std POSIX
1003.1c-1995.

Section 18.1.2 lists the "tmpname()" function on line 65.

This should be "tmpnam()" as on page 205 line 29.

This is a clear contradiction between two sections of the standard, where
the normative section is correct. This should be forwarded to the sponsor, 
so that the IEEE errata correction process be applied.

Interpretation response
------------------------
The standard is clear in section 8.1 on page 205 line 63 that the C
language function tmpnam() shall be provided in the POSIX.1 with C
Language Binding.  The reference in section 18.1.2 page 348 line 65 to a
function 'tmpname()' refers to a function that is not defined anywhere
in the standard and thus represents a defect in the standard.  The
interpretation committee believes that intent of the working and
balloting groups was clear and that this is typographical error. It is
being referred to the sponsor for correction.  

Rationale
-------------
None.

Forwarded to Interpretations group: August 5 1996
Proposed resolution: Jan 17 1997
Finalised: Feb 14 1997

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

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

Last update: 15 April,1997

								1003.1c-95  #29

 _____________________________________________________________________________

	Interpretation Number:	XXXX
	Topic:               Get scheduling parameter limits
	Relevant Sections:   13.3.6

Interpretation Request:
-----------------------

	Date: Tue, 27 Aug 1996 15:27:10 -0400
	From: Dave Butenhof <butenhof@zko.dec.com>
        Standard: 9945-1:1996 (1003.1, 1996 Edition)


3. Section 13.3.6, Get Scheduling Parameter Limits

   The standard fails to formalize the dependency of
   _POSIX_THREAD_PRIORITY_SCHEDULING on _POSIX_PRIORITY_SCHEDULING. That
   is, a conforming implementation could choose to support the latter but
   not the former. That was intentional, BUT, there really is a "hidden"
   dependency... to use thread priority scheduling one must call
   sched_priority_get_min() and/or sched_priority_get_max() to determine
   the legal priority range for any policy. And those functions are
   required only under _POSIX_PRIORITY_SCHEDULING, and therefore might not
   exist. I would suggest one of three solutions:

   1) require _POSIX_PRIORITY_SCHEDULING if the implementation supports
      _POSIX_THREAD_PRIORITY_SCHEDULING, or,
   2) sched_priority_get_min/_max must be required if EITHER option is
      supported, or,
   3) go back to the wording in one of the earlier drafts, where there was
      no separate thread priority scheduling option at all -- the thread
      scheduling functions were present IFF the system supported threads 
      and priority scheduling.

   Option 2 is likely to be the least contentious of the three, and it's
   certainly sufficient.

        REF:    pages 53-54, section 2.9.3, lines 1602-1667
                page 296, section 13.3.6.1, lines 340-341


Interpretation response
------------------------
The standard is clear in section 13.2 that priorities shall be in the
range defined for the policy and in section 13.3.6 it only requires the
sched_get_priority_max and sched_get_priority_min function if
_POSIX_PRIORITY_SCHEDULING is defined.  The standard's conformance
requirement upon these functions when that option is not defined is only
that if the functions are provided, they shall be provided as specified
or they shall fail.  The standard is also clear that the
_POSIX_THREAD_PRIORITY_SCHEDULING option does not require that the
sched_get_priority_max and sched_get_priority_min functions be defined.
The interpretations committee believes that not requiring the definition
of these functions may make the _POSIX_THREAD_PRIORITY_SCHEDULING option
less useful and was not the intention of the working and balloting
groups.  This is being referred to the sponsor for consideration.   

Rationale
-------------

None.

Forwarded to Interpretations group: August 29 1996
Proposed resolution: 29 Jan 97
Finalised: Feb 14 1997

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

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

Last update: 15 April,1997

								1003.1c-95  #30

 _____________________________________________________________________________

	Interpretation Number:	30
	Topic:               Thread Scheduling Functions, Description
	Relevant Sections:   13.5.1.2 

Interpretation Request:
-----------------------

	Date: Tue, 27 Aug 1996 15:27:10 -0400
	From: Dave Butenhof <butenhof@zko.dec.com>
        Standard: 9945-1:1996 (1003.1, 1996 Edition)


4. Section 13.5.1.2, Thread Scheduling Functions, Description

   The standard currently requires that the pthread_attr_setschedparam and
   pthread_attr_getschedparam functions be present if {_POSIX_THREADS} is
   defined, while all other thread scheduling attribute functions are
   present if {_POSIX_THREAD_PRIORITY_SCHEDULING} is defined. It is
   pointless to have pthread_attr_setschedparam without also having
   pthread_attr_setpolicy and pthread_attr_setinheritsched, for
   example. The rationale for this section (B.13.1) makes clear the
   original intent of the working group -- "In this standard, the basic
   thread scheduling functions are defined under the {_POSIX_THREADS}
   option so that they are required of all threads
   implementations. However, there are no specific scheduling policies
   required by this option to allow for conforming thread implementations
   that are not targeted to realtime applications."

   Although it is understood that rationale (however clearly following the
   intent of the working group) is not normative or binding, it is not
   reasonable that all thread implementations support "scheduling
   parameters" but not scheduling policy, or the other mechanism that gives
   scheduling parameters meaning. The standard must be repaired to, at
   least, restore consistency. While the best policy would be to follow the
   intent of the working group, and make all of the scheduling-related
   functions available if {_POSIX_THREADS}, it would be acceptable to make
   them all available only if {_POSIX_THREAD_PRIORITY_SCHEDULING}.

        REF:    pages 300-301, section 13.5.1.2, lines 509, 552
                page 303, section 13.5.2.2, line 599
                page 548, section B.13.1, lines 7897-7901


Interpretation response
------------------------


The standard is clear that on p. 300, line 509,
_POSIX_THREAD_PRIORITY_SCHEDULING} is defined then
the functions:
    pthread_attr_setscope(), pthread_attr_getscope(),
    pthread_attr_setinheritsched(), pthread_attr_getinheritsched(),
    pthread_attr_setschedpolicy(), pthread_attr_getschedpolicy()
shall be provided.

It is also clear on page 301, line 552, that if _POSIX_THREADS is
defined then the functions:
    pthread_attr_setschedparam() and pthread_attr_getschedparam()
shall be provided.  Conforming implementations must conform to these. 

Rationale
-------------

None.

Forwarded to Interpretations group: August 29 1996
Finalised : 27 Mar 1997

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

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

Last update: 15 April,1997

								1003.1c-95  #31

 _____________________________________________________________________________

	Interpretation Number:	XXXX
	Topic:               Dynamic Thread Scheduling Parameters Access, Description
	Relevant Sections:   13.5.2.2

Interpretation Request:
-----------------------

	Date: Tue, 27 Aug 1996 15:27:10 -0400
	From: Dave Butenhof <butenhof@zko.dec.com>
        Standard: 9945-1:1996 (1003.1, 1996 Edition)


5. Section 13.5.2.2, Dynamic Thread Scheduling Parameters Access, Description

   The pthread_getschedparam and pthread_setschedparam functions are
   specified to be available only if {_POSIX_THREAD_PRIORITY_SCHEDULING};
   this is a problem related to the previous issue with Section
   13.5.1. According to the intent of the working group, these functions
   should be available if {_POSIX_THREADS}. (However, if the resolution of
   the previous issue is to make all scheduling functions available only if
   {_POSIX_THREAD_PRIORITY_SCHEDULING}, then this section is correct
   as-is.)

        REF:    pages 300-301, section 13.5.1.2, lines 509, 552
                page 303, section 13.5.2.2, line 599
                page 548, section B.13.1, lines 7897-7901


Interpretation response
------------------------

This was an informational note only, related to interpretation request #30.
No interpretation was requested.
                                   

Rationale
-------------
None.
Forwarded to Interpretations group: August 29 1996
Finalised: Mar 27 1997

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

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

Last update: 15 April,1997

								1003.1c-95  #33

 _____________________________________________________________________________

Interpretation Number:	33
Topic:               Thread Cancellation, Async-Cancel Safety
Relevant Sections:   18.1.4

Interpretation Request:
-----------------------

	Date: Tue, 27 Aug 1996 15:27:10 -0400
	From: Dave Butenhof <butenhof@zko.dec.com>
        Standard: 9945-1:1996 (1003.1, 1996 Edition)


7. Section 18.1.4, Thread Cancellation, Async-Cancel Safety

   pthread_cancel is specified to be async-cancel safe, along with the
   pthread_setcancelstate and pthread_setcanceltype functions. I see
   no reasonable justification for allowing cancellation while async
   cancellation is enabled, nor does the rationale attempt to give any
   justification. I believe that pthread_cancel should be removed from
   the list of async-cancel safe functions. Async cancellation is an
   unusual "aberration", and I see no reason to allow use of any POSIX
   standard functions with async cancellation type except the
   functions required to disable cancellation.

        REF:    page 349, section 18.1.4, line 112



Interpretation for IEEE Std 1003.1c-1995:
-------------------------------------------

The standard is clear that pthread_cancel shall be async-cancel safe, and
conforming implementations must conform to this.  

Rationale
-------------
Requiring pthread_cancel() to be async-cancel safe potentially makes
it easier for helper threads running with asynchronous cancellation
enabled to themselves cancel other threads.  This imposes no undue
burden on implementations since, if necessary, the pthread_cancel()
implementation can always internally set the cancellation state to
defer cancellation while pthread_cancel() is being executed and then
restore the cancellation state after the cancel request has been
executed.   

Forwarded to Interpretations group: August 29 1996
Proposed resolution: 18 Sep 96
Finalised: 27 Jan 97

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

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

Last update: 15 April,1997

								1003.1c-95  #34

 _____________________________________________________________________________

	Interpretation Number:	XXXX
	Topic:               pthread_mutex_init, pthread_cond_init
	Relevant Sections:   11.3.2.2.

Interpretation Request:
-----------------------

	Date: Tue, 03 Sep 1996 10:45:12 -0400
	From: Dave Butenhof <butenhof@zko.dec.com>

1. Section 11.3.2.2 & 11.4.2.2

   The POSIX synchronization functions in section 11 were intended to
   allow use of efficient hardware-based synchronization mechanisms, and
   thus, it is essential that calling code adhere to certain rules. One
   important rule is that code cannot COPY synchronization objects, as
   the copy may not behave the same as the original. The description of
   Semaphore initialization specifically states that "Only sem itself
   may be used for performning synchronization. The result of referring
   to copies of sem in calls to sem_wait, sem_trywait, sem_post, and
   sem_destroy, is undefined."

   I believe that the intent of the working group would be best served
   if a similar restriction had been placed upon code using the
   pthread_mutex_t and pthread_cond_t synchronization objects, but the
   required wording is missing from the standard. Code that currently
   does not violate the standard may thus fail to port to
   implementations of the standard that the working group did not intend
   to exclude. POSIX 1003.1n should amend the standard to require that
   conforming applications shall not copy mutex and condition variable
   synchronization objects, just as is currently required of code using
   POSIX semaphores.

	REF: page 242, section 11.2.1.2, Semaphore Functions Description
	REF: page 255, section 11.3.2.2, Mutex initialization
	REF: page 261, section 11.4.2.2, Condition variable initialization


Interpretation response
------------------------
The standard is clear that it does not restrict the copying of mutex objects and
conforming implementations must allow copies.  However, the interpretations
committee believes that this is not the intent of the working and balloting
groups.  Rather, the intent was to be the same as for semaphores with the effect
of using copies being "undefined".
                                     

Rationale
-------------
Implementations may wish to use hardware support to accelerate the 
performance of the mutex. For this to work, only the 'initial' copy would 
be the hardware and thus shared.

Forwarded to Interpretations group: Sep 8 1996
Finalised: Mar 18 1997

PASC Interpretation Ref: pasc-1003.1c-35
Topic: cancellation points

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

Last update: 15 April,1997

								1003.1c-95  #35

 _____________________________________________________________________________

	Interpretation Number:	XXXX
	Topic:               cancellation points
	Relevant Sections:   18.1.2

Interpretation Request:
-----------------------

	Date: Tue, 03 Sep 1996 10:45:12 -0400
	From: Dave Butenhof <butenhof@zko.dec.com>


2. Section 18.1.2, Cancellation Points

   In the second list ("A cancellation point may also occur"), several
   functions from ISO/ANSI C 1990 are omitted, specifically (at least),
   vprintf and vfprintf. Because printf is present, these should be
   also. (This is critical, since the standard specifically prohibits
   additional cancellation points for functions in POSIX.1 or ISO C.)

	REF: page 348, section 18.1.2, line 65

Interpretation response
------------------------

The standard is clear that vprintf and vfprintf shall not be cancellation
points.  Conforming implementations must conform to this.  However, it
it the opinion of the interpretations committee that this is an oversight
on the part of the working and balloting groups and that they may be
a cancellation point.  This is being referred to the sponsor for consideration.
          

Rationale
-------------
Printf may be a cancellation point and it is inconsistent to not also allow
vprintf and vfprintf. 

Forwarded to Interpretations group: Sep 8 1996
Proposed resolution: 17 Jan 1997
Finalised resolution: 18 Mar 1997

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

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

Last update: 15 April,1997

								1003.1c-95  #36

 _____________________________________________________________________________

	Interpretation Number:	XXXX
	Topic:               primitive system data types
	Relevant Sections:   2.5

Interpretation Request:
-----------------------


	Date: Mon, 07 Oct 1996 14:41:09 -0400
	From: Dave Butenhof (butenhof@zko.dec.com)

1. Section 2.5, Primitive System Data Types

   The pthread data types (pthread_t, pthread_attr_t, pthread_cond_t,
   pthread_condattr_t, pthread_mutex_t, pthread_mutexattr_t,
   pthread_key_t, pthread_once_t) are listed in this section, and in
   Table 2-1. Unfortunately, while all of these types have been
   specifically described as "opaque" types (and 2.5 even reminds
   readers that there are "no defined comparison or assignment
   operators" for most of the types, oddly omitting some), The second
   paragraph of this section says clearly "All of the types listed in
   Table 2-1 shall be arithmetic types".

1a)   This is not true, and the working group did not intend to make this
   a requirement. Either the statement should be changed, for example,
   to list the specific types that must be arithmetic, or to exclude
   all of those that needn't be -- or else the non arithmetic types
   (all the pthread types) should be moved to a separate table.

1b)   In addition, the list of types for which there are no defined
   comparison or assignment operators omits pthread_key_t and
   pthread_once_t, both of which are also "opaque types", and have no
   comparison or assignment operators.


Interpretation response
-----------------------

The standard is unclear on this issue, and no conformance distinction
can be made between alternative implementations based on this.
This is being referred to the sponsor. 

Rationale
-------------

As noted in the request these types are described elsewhere in the
standard as opaque types as an aid to extensibility. Although not
part of the normative text, the rationale for POSIX 1003.1c/D10
makes it very clear that these are opaque data types.

Furthermore, the text in lines 970-972 that "There are no defined
comparison or assignment operators for the types pthread_attr_t,
pthread_cond_t, pthread_condattr_t, pthread_mutex_t, and
pthread_mutex_attr_t." contradicts the claim on line 963 that these
types shall be arithmetic, since all arithmetic types have defined
comparison and assignment operators.  

The interpretations committee recommends to the sponsor that the
following changes be made:           

Proposed changes to 1003.1 (not part of this interpretation).
--------------------------

Change 1003.1-1996 ll 963 first sentence from
"All of the types listed in Table 2-1 shall be arithmetic types;"
To:
"All of the types listed in Table 2-1 shall be arithmetic types,
except the types pthread_t, pthread_attr_t, pthread_mutex_t,
pthread_mutexattr_t, pthread_cond_t, pthread_condattr_t, pthread_key_t,
pthread_once_t;"

Forwarded to Interpretations group: Oct 20 1996
Proposed interpretation:29 Jan 97
Finalised: Feb 18 1997

PASC Interpretation Ref: pasc-1003.1c-38
Topic: mutex

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

Last update: 15 April,1997

								1003.1c-95  #38

 _____________________________________________________________________________

	Interpretation Number:	XXXX
	Topic:               mutex
	Relevant Sections:   2.2.2.68

Interpretation Request:
-----------------------

	From: Andrew Josey (on behalf of the X/Open Base working group)

Part 1. Interpretation Request for:
   IEEE Std 1003.1c-1995 as contained in:
   ISO/IEC 9945-1:1996(E), ANSI/IEEE Std. 1003.1, 1996 Edition.
   Subsection 2.2.2.68, Page 20, Line 308.

Question:
Why does a mutex only allow multiple threads to serialize their access to
"shared data"? A mutex may be used to provide mutual exclusion among threads
trying to access any sort of shared resource. For example, several threads
may occasionally need to utilize a single hardware co-processor, and may
serialize access to that resource with a mutex even though it isn't "shared
data".

Suggested Correction:
Change the phrase "shared data" to "shared resources".

Interpretation response
------------------------
The part of the definition cited is informative in scope and does not
require any restrictions on conforming applications.  The proposed
change may add some additional clarity and will be referred to the
sponsor for consideration.  


Rationale
-------------
The wording of the particular sentence is neither binding upon the
application, nor is it constrained by the interface, and it is not
testable by a conformance test.  Changing 'data' to 'resources' may help
someone inexperienced in this area but does not seem to make a
significant improvement in the standard. 

Forwarded to Interpretations group: Dec 9 1996
Proposed resolution: Jan 29 1997
Finalised: Feb 20 1997

PASC Interpretation Ref: pasc-1003.1c-39
Topic: thread - safety

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

Last update: 15 April,1997

								1003.1c-95  #39

 _____________________________________________________________________________

	Interpretation Number:	XXXX
	Topic:               thread - safety
	Relevant Sections:   2.3.9

Interpretation Request:
-----------------------

	From: Andrew Josey (on behalf of the X/Open Base working group)

Part 1. Interpretation Request for:
   IEEE Std 1003.1c-1995 as contained in:
   ISO/IEC 9945-1:1996(E), ANSI/IEEE Std. 1003.1, 1996 Edition.
   Subsection 2.3.9, Page 32, Line 754-761.

Question:
The referenced paragraph says that all POSIX.1 and ISO C functions except
those enumerated within the paragraph shall be thread safe. Why are the
functions getenv(), localeconv(), and strerror() not in the list of exceptions?
Their absence implies that they SHALL be thread safe, yet their definitions
each state that the object pointed to by their return value MAY be overwritten
by a subsequent call to the same function. If this is the case, implementations
cannot provide thread safety through internal synchronization because the return
object as seen by one thread may be corrupted by another thread AFTER the
function returns to the first thread, but before the first thread is finished
utilizing or copying the object. Although it is quite possible for an
implementation to provide these in a thread safe fashion using thread specific
data with destructors, the function definitions allow non-thread safe behavior,
directly contradicting this paragraph. These 3 functions fall into the same
general category as asctime() or ttyname(), and should be in this list.  In the
future, thread safe versions of these functions should be included in the
standard (getenv_r, localeconv_r, strerror_r).

Suggested Correction:
Add getenv(), localeconv(), and strerror() to the list of functions that need
not be thread safe.


Interpretation response
------------------------
The standard is clear that getenv(), localeconv(), and strerror() must
be thread-safe. A conforming implementations shall satisfy this
condition.

However, concerns have been raised in the interpretation committee that
this was not the intent of the working and balloting groups.  This is
being referred to the sponsor consideration.     


Rationale
-------------
It appears that the standard has a defect - the working group and the
balloting group seems to have missed these three functions. Note, that
the standard states that all POSIX.1 and ISO C be functions be thread
safe but for a list of exceptions that have _r equivalents. These
functions should have been part of the list of exceptions.

A getenv_r() function should clearly be added.  Likewise requirements
for localeconv_r() and strerror_r() should added for systems that
provide localeconv() and strerror().  (Note that these ANSI C
functions are not required by IEEE Std 1003.1.) 

Forwarded to Interpretations group: Dec 9 1996
Proposed resolution: Jan 17 1997
Finalised: Feb 14 1997

PASC Interpretation Ref: pasc-1003.1c-40
Topic: sigsuspend

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

Last update: 15 April,1997

								1003.1c-95  #40

 _____________________________________________________________________________

	Interpretation Number:	XXXX
	Topic:               sigsuspend
	Relevant Sections:   3.3.7.3

Interpretation Request:
-----------------------

	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.
   Subsection 3.3.7.3, Page 87, Line 1203.

Question:
Is the phrase "Since the sigsuspend() function suspends process execution
indefinitely," correct? It is clear from line 1190 that the function suspends
the calling "thread", but why would the "process" be suspended indefinitely?

Suggested Correction:
Change the phrase to "Since the sigsuspend() function suspends thread execution
indefinitely,".


Interpretation response
-----------------------
The standard is clear that sigsuspend shall suspend the calling
thread until the delivery of a signal.  The explanatory subclause in
the returns section is not a correct representation of what happens
and this is being referred to the sponsor for correction as an
editorial error. 


Rationale
-------------
In the the declaritive text of the description for sigsuspend(), the
wording is very clear that the function will suspend the thread.  The
Interpretations Committee is believes that this is exactly what was
intended by the working and balloting groups.  The subclause in the
returns section is clearly explanitory but does not match what the
declaritive text states and is incorrect.  During development of the
standard, there were several changes made that required changing
process to thread and this was one that was missed.  


Forwarded to Interpretations group: Dec 9 1996
Proposed resolution: 29 Jan 97
Finalised: Feb 14 1997