Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001383 [Issue 8 drafts] System Interfaces Editorial Enhancement Request 2020-07-25 11:24 2020-10-08 10:27
Reporter dannyniu View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied   Product Version Draft 1
Name DannyNiu/NJF
Organization
User Reference
Section Fork
Page Number 878
Line Number 29985
Final Accepted Text Note: 0004997
Summary 0001383: Make "Application Usage" less confusing.
Description The "Application Usage" section has new content that's
added in response to Bug 62, but right now it has a
confusing (at least on the first sight) wording that's
unfriendly to new readers not familiar to the modification
made to fork.

Specifically, it says:

> processing performed in the child before fork() returns

On the first sight, it seems nonsensical as child doesn't
even exist before fork returns, however, when reminded of
pthread_atfork handlers, it makes sense.
Desired Action Change

> processing performed in the child before fork() returns

To

> processing performed in the child by the pthread_atfork()
> handlers before fork() returns
Tags issue8
Attached Files

- Relationships
related to 0001114Applied 1003.1(2016/18)/Issue7+TC2 Clarify if fork preserves thread resources 

-  Notes
(0004900)
geoffclare (manager)
2020-07-27 09:07

This change was not made as a result of bug 0000062, it is from the unrelated bug 0001114.

Where the new text refers to "processing performed in the child before fork() returns" it means everything that the implementation of fork() does in the child between the point where it creates the child process and the point where it returns in the child process. This includes any processing related to the bullet list on lines 29903-29957.

Rather than adding a reference to pthread_atfork() (which would incorrectly imply that the text only applies to processing performed by atfork handlers) we should make it clear that the text applies to both fork() and _Fork().
(0004901)
geoffclare (manager)
2020-07-27 09:13

Suggested change...

On page 878 line 29980 section fork(), change:
When a multi-threaded process calls fork(), ...
to:
When a multi-threaded process calls fork() or _Fork(), ...

On page 878 line 29985 section fork(), change:
the processing performed in the child before fork() returns
to:
the processing performed in the child before fork() or _Fork() returns in the child
(0004902)
shware_systems (reporter)
2020-07-27 14:40

Upon rereading 1114, I'm more inclined second change in Note 4901 should start 'any processing', not 'the processing', to be inclusive of any implementations that set up the child's data space entirely before handing it off to the process scheduler, where this is plausible. Use of 'the' implies there will always be post handoff manipulations.
(0004997)
rhansen (manager)
2020-09-17 16:03

On page 878 line 29980 (fork() application usage), change:
When a multi-threaded process calls fork(), although all memory that is addressable in the calling thread remains addressable in the child, there is no guarantee that the contents of thread-specific memory, such as stacks or thread-local storage, that was specific to other threads in the parent will still be the same in the child. This is because such memory could be treated as available in the child given that the threads it related to do not exist in the child, and consequently the processing performed in the child before fork() returns could make use of that memory. Therefore applications should avoid using in the child any pointers to thread-specific memory that were passed to the calling thread from other threads in the parent.
to:
When a multi-threaded process calls fork() or _Fork(), there is no guarantee that thread-specific memory (such as stacks or thread-local storage) associated with threads in the parent other than the calling thread will still be available in the child. This is because threads in the parent other than the calling thread do not exist in the child. Consequently, the implementation of fork() and _Fork() could remove that memory from the address space in the child, or reuse it for other purposes before returning or (in the case of fork()) calling any of the fork handlers registered by pthread_atfork(). Therefore, applications should avoid using any pointers to thread-specific memory in the child that were passed to the calling thread from other threads in the parent.

- Issue History
Date Modified Username Field Change
2020-07-25 11:24 dannyniu New Issue
2020-07-25 11:24 dannyniu Name => DannyNiu/NJF
2020-07-25 11:24 dannyniu Section => Fork
2020-07-25 11:24 dannyniu Page Number => 878
2020-07-25 11:24 dannyniu Line Number => 29985
2020-07-27 09:07 geoffclare Note Added: 0004900
2020-07-27 09:07 geoffclare Relationship added related to 0001114
2020-07-27 09:13 geoffclare Note Added: 0004901
2020-07-27 14:40 shware_systems Note Added: 0004902
2020-09-17 16:03 rhansen Note Added: 0004997
2020-09-17 16:06 rhansen Tag Attached: issue8
2020-09-17 16:07 rhansen Final Accepted Text => Note: 0004997
2020-09-17 16:07 rhansen Status New => Resolved
2020-09-17 16:07 rhansen Resolution Open => Accepted As Marked
2020-10-08 10:27 geoffclare Status Resolved => Applied


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker