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

Last update: 10 April,2001

								1003.1-96  #119

 _____________________________________________________________________________

	Interpretation Number:	XXXX
	Topic:			sigtimedwait and EAGAIN error
	Relevant Sections:	page 90, clause 3.3.84, ll 1295-1296


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

	Date: 2000 Nov 29

Address details:

The Open Group
Apex Plaza 
Forbury Road
Reading 
RG1 1AX

------------------------------------------------------------------------ 

 7  Defect Report concerning (number and title of International Standard
    or DIS final text, if applicable): 

IEEE Std 1003.1-1996 (incorporates 1003.1-1990, 1003.1b-1993, 1003.1c-1995, 1003.1i-1995) (ISO 9945-1:1996)

------------------------------------------------------------------------ 

 8  Qualifier (e.g. error, omission, clarification required):

3

Error=1 , Omission=2, Clarification=3

------------------------------------------------------------------------ 

 9  References in document (e.g. page, clause, figure, and/or table
    numbers):

page 90, clause 3.3.84, ll 1295-1296

------------------------------------------------------------------------ 

10  Nature of defect (complete, concise explanation of the perceived
    problem):


Austin Group XSHd1 ERN 345 stated the following problem
(to be clear these are the words of the originator of the ERN):


ETIMEDOUT is used for pthread_cond_timedwait() in exactly the same
context. Normally EAGAIN is reserved for use when some resource 
limit temporarily causes failure of an API, while ETIMEDOUT is 
specified for a user-specified timeout.
Also, all of the realtime amendments in progress use ETIMEDOUT 
for this.  I believe there is either an interp request or an 
unresolved  objection against .1a calling for this to be made 
consistent.

Action:
Consider changing this to ETIMEDOUT unless the potential for 
breakage is too great.

------------------------------------------------------------------------ 

11  Solution proposed by the submitter (optional):

The standard is clear in its requirement for EAGAIN. 
The issue is whether the standard has a defect.

In hindsight ETIMEDOUT would seem a more appropriate error,
however would that break applications?



------------------------------------------------------------------------ 




Interpretation response
------------------------
The standard clearly states the requirements ,and conforming implementations 
must conform to this. To change this would break backwards compatibility.
No change is required.

Rationale
-------------
There is very little reason one would use sigtimedwait() without intending
to check for timeout, so we would expect most users of this interface
to be broken by the proposed change.

Whilst consistency is desirable, there appears to be no way to make
a change without breaking source compatibility.



Forwarded to Interpretations group: 29 Nov 2000
Proposed resolution: 15 Feb 2001
Finalised: 15 Mar 2001