The following issue has been SUBMITTED. 
====================================================================== 
http://austingroupbugs.net/view.php?id=1162 
====================================================================== 
Reported By:                Villemoes
Assigned To:                ajosey
====================================================================== 
Project:                    1003.1(2008)/Issue 7
Issue ID:                   1162
Category:                   System Interfaces
Type:                       Clarification Requested
Severity:                   Editorial
Priority:                   normal
Status:                     Under Review
Name:                       Rasmus Villemoes 
Organization:                
User Reference:              
Section:                    pthread_cond_timedwait 
Page Number:                 
Line Number:                 
Interp Status:              --- 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2017-09-20 12:18 UTC
Last Modified:              2017-09-20 12:18 UTC
====================================================================== 
Summary:                    EOWNERDEAD must have precedence over ETIMEDOUT
Description: 
If a thread wakes up from a pthread_cond_timedwait due to the deadline
passing, and when trying to reacquire the mutex finds it in an EOWNERDEAD
state, the return value from the pthread_cond_timedwait must be EOWNERDEAD
rather than ETIMEDOUT - but AFAICT, this is not explicitly stated in the
specification. The closest mention I can find is

  If mutex is a robust mutex where an owner terminated while holding the
lock and the state is recoverable, the mutex shall be acquired even though
the function returns an error code.

but "an error code" doesn't preclude ETIMEDOUT.

(If the application wants to know whether the deadline has passed, it can
always do that with an extra call to clock_gettime, but it has no way of
detecting the EOWNERDEAD state.)

Desired Action: 
Clarify which return value the application can expect when a condition
variable is used with a robust mutex.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2017-09-20 12:18 Villemoes      New Issue                                    
2017-09-20 12:18 Villemoes      Status                   New => Under Review 
2017-09-20 12:18 Villemoes      Assigned To               => ajosey          
2017-09-20 12:18 Villemoes      Name                      => Rasmus Villemoes
2017-09-20 12:18 Villemoes      Section                   =>
pthread_cond_timedwait
======================================================================


Reply via email to