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-15 17:16 |
| Reporter | dannyniu | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Clarification Requested |
| Status | Interpretation Required | Resolution | Accepted As Marked | ||
| Name | DannyNiu/NJF | ||||
| Organization | |||||
| User Reference | |||||
| Section | <pthread.h> `pthread_equal` | ||||
| Page Number | 239, 1722 | ||||
| Line Number | 11576, 57189-57227 | ||||
| Interp Status | Pending | ||||
| Final Accepted Text | 0001965:0007363 | ||||
| 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 | tc1-2024 | ||||
|
|
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. |
|
|
The reason I initially opened this issue, is because of a desire to let signal handlers installed by `sigaction` to be able to do processing in a thread-specific manner - signal handlers are associated with the process, so I thought there needed a way to identify the thread in which the signal handler is executed in. My half-smart partial solution is to have an array containing a thread identifier and a thread-specific context (e.g. a `void *`), and perform a linear-time look up on it, and `pthread_equal()` is an essential ingredient. So it's more of a application-side use case rather than a specificational consistency need. I wonder if such application need worth the discussion. To quote a precedence, O_CLOFORK was introduced for application need wasn't it? |
|
|
Interpretation response ------------------------ The standard states that pthread_equal() need not be async-signal-safe, and conforming applications must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: ------------- It is believed that no pthread interfaces were required to be async-signal-safe in the original POSIX.1c threads amendment because the standard allowed implementations to define pthread_t as a structure type. However, now that the standard requires pthread_kill() to be async-signal-safe, any such implementation would need a way to pass a pthread_t structure to pthread_kill() in an async-signal-safe manner and thus would be able to use the same method to pass a pthread_t to pthread_equal(). Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Add pthread_equal() to the list of async-signal-safe functions. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-12-21 06:49 | dannyniu | New Issue | |
| 2026-01-06 10:02 | geoffclare | Note Added: 0007352 | |
| 2026-01-10 04:26 | dannyniu | Note Added: 0007362 | |
| 2026-01-10 04:29 | dannyniu | Note Edited: 0007362 | |
| 2026-01-15 17:16 | geoffclare | Note Added: 0007363 | |
| 2026-01-15 17:16 | geoffclare | Status | New => Interpretation Required |
| 2026-01-15 17:16 | geoffclare | Resolution | Open => Accepted As Marked |
| 2026-01-15 17:16 | geoffclare | Interp Status | => Pending |
| 2026-01-15 17:16 | geoffclare | Final Accepted Text | => 0001965:0007363 |
| 2026-01-15 17:16 | geoffclare | Tag Attached: tc1-2024 |
