|
Viewing Issue Simple Details
[ Jump to Notes ]
|
[ Issue History ]
[ Print ]
|
|
ID |
Category |
Severity |
Type |
Date Submitted |
Last Update |
|
0001361 |
[Issue 8 drafts] System Interfaces |
Objection |
Error |
2020-07-02 13:52 |
2024-06-11 09:12 |
|
|
Reporter |
geoffclare |
View Status |
public |
|
|
Assigned To |
|
|
Priority |
normal |
Resolution |
Accepted |
|
|
Status |
Closed |
|
Product Version |
Draft 1 |
|
|
Name |
Geoff Clare |
|
Organization |
The Open Group |
|
User Reference |
|
|
Section |
fork() |
|
Page Number |
877 |
|
Line Number |
29947 |
|
Final Accepted Text |
|
|
|
Summary |
0001361: fork() changes incomplete |
|
Description |
The changes from bug 0000062 to add _Fork() and make fork() non-async-signal-safe missed some things on the fork() page:
The text "When the application calls fork() from a signal handler and any of the fork handlers registered by pthread_atfork() calls a function that is not async-signal-safe, the behavior is undefined" in one of the later bullet items is redundant now that fork() itself is not async-signal-safe.
There is a paragraph in RATIONALE explaining why the above text is there.
|
|
Desired Action |
On page 877 line 29947 section fork(), delete:When the application calls fork() from a signal handler and any of the fork handlers registered by pthread_atfork() calls a function that is not async-signal-safe, the behavior is undefined.
On page 879 line 30059 section fork(), delete:While the fork() function is async-signal-safe, there is no way for an implementation to determine whether the fork handlers established by pthread_atfork() are async-signal-safe. The fork handlers may attempt to execute portions of the implementation that are not async-signal- safe, such as those that are protected by mutexes, leading to a deadlock condition. It is therefore undefined for the fork handlers to execute functions that are not async-signal-safe when fork() is called from a signal handler. |
| Tags |
issue8 |
|
|
Attached Files |
|
|
|
Relationships 
