0000759: Is "may fail" case adequately specified?

ID	Project	Category	View Status	Date Submitted	Last Update

0000759	1003.1(2013)/Issue7+TC1	System Interfaces	public	2013-09-24 00:24	2013-10-17 15:40

Reporter	shware_systems	Assigned To
Priority	normal	Severity	Comment	Type	Clarification Requested
Status	Closed	Resolution	Rejected

Name	Mark Ziegast
Organization
User Reference
Section	pthread_mutex_lock(), pthread_mutexattr_get, setrobust()
Page Number	1654, 1674
Line Number	53619, 54314
Interp Status	---
Final Accepted Text


Summary	0000759: Is "may fail" case adequately specified?
Description	Re: #0748 "The problem is that if the "may fail" EOWNERDEAD case is not supported, and the process containing the terminated thread does not terminate, then the mutex cannot be acquired - any attempt to do so will either block indefinitely, fail with EBUSY, or timeout." Is this the only behavior considered normative for if EOWNERDEAD isn't supported, that it behave as a non-robust mutex? If so, it seems making that explicit may be needed. For both here and mutex_lock( ) pages I think the language leaves open, at least for implementation provided mutexes, some degree of automatic attempt to make the protected state consistent and return success, but this isn't indicated. I can also see, though non-portable, returning a different error value, e.g. ETHREADDEAD, to differentiate from the process-died case. An implementation-defined signal being raised with mutex address as parameter also might be usable to make the state consistent in the signal handler and call mutex_consistent( ) there before the lock interfaces return so they succeed, or return ENOTRECOVERABLE instead directly. A SIGIGN on this signal could still return EOWNERDEAD.
Desired Action	Clarify alternative portable behaviors for when EOWNERDEAD is not returned in the "thread died but app hasn't" may fail case, or provide cross reference to existing text.
Tags	No tags attached.

Date Modified	Username	Field	Change
2013-09-24 00:24	shware_systems	New Issue
2013-09-24 00:24	shware_systems	Name	=> Mark Ziegast
2013-09-24 00:24	shware_systems	Section	=> pthread_mutex_lock(), pthread_mutexattr_get, setrobust()
2013-09-24 00:24	shware_systems	Page Number	=> 1654, 1674
2013-09-24 00:24	shware_systems	Line Number	=> 53619, 54314
2013-10-17 15:32	nick	Relationship added	related to 0000748
2013-10-17 15:40	geoffclare	Interp Status	=> ---
2013-10-17 15:40	geoffclare	Note Added: 0001928
2013-10-17 15:40	geoffclare	Status	New => Closed
2013-10-17 15:40	geoffclare	Resolution	Open => Rejected

View Issue Details

Relationships

Activities

Issue History

geoffclare 2013-10-17 15:40 manager bugnote:0001928	When an error is "may fail", it is optional whether an implementation of the function detects the error condition. If the function detects the condition it must return the specified error. If it doesn't detect the condition, it carries on as if the condition hadn't occurred.