|
Viewing Issue Simple Details
[ Jump to Notes ]
|
[ Issue History ]
[ Print ]
|
|
ID |
Category |
Severity |
Type |
Date Submitted |
Last Update |
|
0001668 |
[Issue 8 drafts] System Interfaces |
Objection |
Enhancement Request |
2023-04-14 05:46 |
2023-06-12 15:37 |
|
|
Reporter |
dannyniu |
View Status |
public |
|
|
Assigned To |
|
|
Priority |
normal |
Resolution |
Rejected |
|
|
Status |
Closed |
|
Product Version |
Draft 3 |
|
|
Name |
DannyNiu/NJF |
|
Organization |
|
|
User Reference |
|
|
Section |
<complex.h> <fenv.h> <tgmath.h> <math.h> [2.9.5 Thread Cancellation] |
|
Page Number |
Many |
|
Line Number |
Many |
|
Final Accepted Text |
|
|
|
Summary |
0001668: Math-related functions are conceptually async-cancel-safe. |
|
Description |
Currently, only 3 functions related to thread cancellation are required to be thread cancellation-safe. However, the class of "pure-computation" functions are also safe, such as those in the 4 mathematical headers listed above.
Cancellation is a mean to give up an ongoing computation that's no longer needed. Floating computation is one such example. Typical floating point computation involve FP CPU instructions, FP error handling and rounding attribute states - all these information are per-thread, and can be safely destroyed when a thread is cancelled.
Even if some implementation may be emulating FP in-kernel, FP environment and the emulation codes that carries out FP computation are conceptually still per-thread, and I see no reason for them to exist in inconsistent state after the thread is cancelled.
Additionally, we may consider some integer functions (e.g. div) to also be async-cancel-safe. |
|
Desired Action |
Decide if to add maths interfaces to the list of async-cancel-safe functions. |
| Tags |
No tags attached. |
|
|
Attached Files |
|
|
|
Relationships 
