|
Viewing Issue Simple Details
[ Jump to Notes ]
|
[ Issue History ]
[ Print ]
|
|
ID |
Category |
Severity |
Type |
Date Submitted |
Last Update |
|
0001162 |
[1003.1(2008)/Issue 7] System Interfaces |
Editorial |
Clarification Requested |
2017-09-20 12:18 |
2024-06-11 08:52 |
|
|
Reporter |
Villemoes |
View Status |
public |
|
|
Assigned To |
ajosey |
|
Priority |
normal |
Resolution |
Accepted As Marked |
|
|
Status |
Closed |
|
|
|
|
|
Name |
Rasmus Villemoes |
|
Organization |
|
|
User Reference |
|
|
Section |
pthread_cond_timedwait |
|
Page Number |
1617 |
|
Line Number |
52757-52759 |
|
Interp Status |
--- |
|
Final Accepted Text |
See Note: 0004230 |
|
|
Summary |
0001162: 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. |
| Tags |
tc3-2008 |
|
|
Attached Files |
|
|
|
Relationships 
