|
Viewing Issue Simple Details
[ Jump to Notes ]
|
[ Issue History ]
[ Print ]
|
|
ID |
Category |
Severity |
Type |
Date Submitted |
Last Update |
|
0001404 |
[1003.1(2016/18)/Issue7+TC2] System Interfaces |
Editorial |
Clarification Requested |
2020-09-24 00:44 |
2024-06-11 09:08 |
|
|
Reporter |
dalias |
View Status |
public |
|
|
Assigned To |
|
|
Priority |
normal |
Resolution |
Accepted As Marked |
|
|
Status |
Closed |
|
|
|
|
|
Name |
Rich Felker |
|
Organization |
musl libc |
|
User Reference |
|
|
Section |
pthread_mutex_destroy |
|
Page Number |
(page or range of pages) |
|
Line Number |
(Line or range of lines) |
|
Interp Status |
--- |
|
Final Accepted Text |
Note: 0005232 |
|
|
Summary |
0001404: Is there a requirement to destroy mutex before object lifetime ends? |
|
Description |
The specification of pthread_mutex_destroy establishes conditions under which behavior of call to pthread_mutex_destroy is undefined, but does not cover whether there are conditions under which failure to call it is undefined. If the lifetime of a pthread_mutex_t object with automatic or allocated storage duration (or mmap/MAP_ANON) ends (end of execution of block, call to free, munmap, etc.) without a call to pthread_mutex_destroy, is or should the behavior be undefined?
I tend to believe it should be undefined, because the intent of having init/destroy functions seems to be to allow implementation flexibility that would include things like keeping a linked list of all existant objects for error-checking (necessary for diagnostic of double init, etc.), using allocation in pthread_mutex_init (in which failure to call pthread_mutex_destroy is a memory leak, which although not inherently fatal, is bad), and so on.
|
|
Desired Action |
Possibly add text to description:
"If the lifetime of an initialized pthread_mutex_t object ends without a call to pthread_mutex_destroy, the behavior is undefined."
It's likely that this proposal needs further discussion, particularly for the case of process-shared objects living in MAP_SHARED (and maybe also MAP_ANON) memory where the end of the object lifetime is not well-defined, and where it may be desirable to allow omission of pthread_mutex_destroy because of software that relies on the shared memory ceasing to exist when the last user unmaps it.
If an action is taken on this, similar actions are probably needed for other pthread object types.
|
| Tags |
tc3-2008 |
|
|
Attached Files |
|
|
|
Relationships 
