Defect Report concerning: IEEE Std. 1003.1c-1995, ISO/IEC 9945-1:1990 AMD 2 - Threads
Clause: 17.1.1.2
PASC Interpretation Ref: pasc-1003.1c-08
Topic: pthread_key_create()


This is an unapproved interpretation of PASC 1003.1c-1995, ISO/IEC 9945-1:1990 AMD 2 - Threads.

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

Last update: 30 March,1998


								1003.1c-95  #8

 _____________________________________________________________________________

	Interpretation Number:	XXXX
	Topic:               pthread_key_create()
	Relevant Sections:   17.1.1.2

Interpretation Request: (Defect Report)
-----------------------

There seems to be an editorial error in POSIX 1003.1c 
regarding pthread_key_create()

The pthread_key_create section 17.1.1.2 of P1003.1c is very unclear.  As
written today it easily leads one to believe that it is required that
the destructor function be called until the thread-specific value
becomes NULL, or until PTHREAD_DESTRUCTOR_ITERATIONS iterations have
occured, which ever comes first.

If you read the draft POSIX 1003.1c standard revisions, it's clear what
the intent was. Between draft standards a sentance was lost which said
"Before each destructor is called, the thread's value for the
corresponding key is set to NULL".

The re-iteration exists so that if the destructor uses keys, they will
be destroyed in a re-call to the destructor.

Was this omission an editorial error?

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

The standard states that the destructor is called with the current 
associated value as its only argument and it is repeatedly called 
until PTHREAD_DESTRUCTOR_ITERATIONS or the value associated with the 
key becomes null.  Conforming implementations must conform to this.  
However, concerns have been raised that the intent of the working and 
balloting groups was somewhat different and that the associated value 
should automatically set to NULL before the destructor is called in 
order to prevent infinite loops.  This is needed since the destructor 
function does not have a way to determine which key that caused it 
to be invoked and thus does not have a way to null the value.  The 
committee feels that this is a problem and it is being refering it 
to the sponsor for consideration.

Rationale
-------------
None.
Forwarded to Interpretations group: May 28 1996
Finalised: July 10th 1996.