View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001965 | 1003.1(2024)/Issue8 | System Interfaces | public | 2025-12-21 06:49 | 2026-01-06 10:02 |
| Reporter | dannyniu | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Clarification Requested |
| Status | New | Resolution | Open | ||
| Name | DannyNiu/NJF | ||||
| Organization | |||||
| User Reference | |||||
| Section | <pthread.h> `pthread_equal` | ||||
| Page Number | 239, 1722 | ||||
| Line Number | 11576, 57189-57227 | ||||
| Interp Status | |||||
| Final Accepted Text | |||||
| Summary | 0001965: Why isn't pthread_equal async-signal safe? | ||||
| Description | Currently there are 4 pthread_* functions that're async-signal-safe, including pthread_self. IMHO, there's no reason to not make pthread_equal safe, unless during some thread control operation, some function would modify the internal data structure if pthread_t is not a scalar. Additionally, unless some implementation _does_ alter pthread_t handle, I think it's perfectly fine to require that the arguments be const-qualified, or that pthread_t be a pointer to a const-qualified data structure. | ||||
| Desired Action | Clarify whether and why pthread_equals isn't an async-signal-safe function. | ||||
| Tags | No tags attached. | ||||
|
|
In POSIX.1-1996 and SUSv3/POSIX.1-2001 there were no pthread_* functions in the async-signal-safe list. The reason that four of them have since been added is to resolve issues. For example, pthread_self() and pthread_kill() are required to be async-signal-safe because raise() is required to be both async-signal-safe and equivalent to pthread_kill(pthread_self(), sig). So the reason pthread_equal() is not required to be safe is because there is no known issue that would be resolved by requiring it to be safe. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-12-21 06:49 | dannyniu | New Issue | |
| 2026-01-06 10:02 | geoffclare | Note Added: 0007352 |
