View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001114 | 1003.1(2016/18)/Issue7+TC2 | System Interfaces | public | 2017-01-12 16:05 | 2024-06-11 09:09 |
| Reporter | Florian Weimer | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Clarification Requested |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Florian Weimer | ||||
| Organization | Red Hat | ||||
| User Reference | |||||
| Section | fork | ||||
| Page Number | unknown | ||||
| Line Number | unknown | ||||
| Interp Status | --- | ||||
| Final Accepted Text | 0001114:0004055 | ||||
| Summary | 0001114: Clarify if fork preserves thread resources | ||||
| Description | The current specification says this: “If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources.” I find it pretty clear that thread stacks and TLS variables have to be replicated in the new process as well, for all threads (not just the current thread), at least for objects whose address has been published to the current process. However, there is some debate whether the current wording allows deallocation of thread stacks in the new process at fork time. | ||||
| Desired Action | Clarify that all thread resources are replicated, perhaps like this: “the calling thread and the entire address space of the parent process” And add a new sentence: “Addressable thread-specific resources, such as objects declared on the stack and TLS variables, are replicated for all threads, not just the current thread. The fork function call does not cause any threads to exit.” The lack of thread exit means that destructors registered with pthread_key_create are not called. Related glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19430 | ||||
| Tags | tc3-2008 | ||||
| related to | 0001383 | Closed | Issue 8 drafts | Make "Application Usage" less confusing. |
|
|
The alternative perspective is that things like on-stack data belong to a particular thread, and are bound to the lifetime of the thread. Therefore, if fork() replicates just the calling thread but not all other threads that may exist, the stacks of those other threads also do not need to be replicated; they would have no owner. |
|
|
This was discussed in the July 12 and July 19, 2018 teleconferences. We believe no change is needed to the normative text of the standard. It clearly states that the child contains a replica of the calling thread's entire address space. The request to change this to specify the process's address space would make no difference since the address space of the thread and the process are one and the same. This is clear from XBD 3.404 Thread: "Anything whose address may be determined by a thread, including but not limited to static variables, storage obtained via malloc(), directly addressable storage obtained through implementation-defined functions, and automatic variables, are accessible to all threads in the same process." The standard is also clear that a process is created with a single thread. Any additional threads in the parent simply don't exist in the child; they aren't terminated because in order to be terminated they would first have to exist. |
|
|
On page 899 line 30368 section fork(), change APPLICATION USAGE from:None.to: 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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-01-12 16:05 | Florian Weimer | New Issue | |
| 2017-01-12 16:05 | Florian Weimer | Name | => Florian Weimer |
| 2017-01-12 16:05 | Florian Weimer | Organization | => Red Hat |
| 2017-01-12 16:05 | Florian Weimer | Section | => fork |
| 2017-01-12 16:05 | Florian Weimer | Page Number | => unknown |
| 2017-01-12 16:05 | Florian Weimer | Line Number | => unknown |
| 2017-01-12 16:50 | torvald | Note Added: 0003541 | |
| 2018-07-19 15:20 | geoffclare | Note Added: 0004054 | |
| 2018-07-19 15:22 | geoffclare | Note Added: 0004055 | |
| 2018-07-19 15:23 | geoffclare | Interp Status | => --- |
| 2018-07-19 15:23 | geoffclare | Final Accepted Text | => 0001114:0004055 |
| 2018-07-19 15:23 | geoffclare | Status | New => Resolved |
| 2018-07-19 15:23 | geoffclare | Resolution | Open => Accepted As Marked |
| 2018-07-19 15:23 | geoffclare | Tag Attached: tc3-2008 | |
| 2019-10-30 10:34 | geoffclare | Status | Resolved => Applied |
| 2020-07-27 09:07 | geoffclare | Relationship added | related to 0001383 |
| 2024-06-11 09:09 | agadmin | Status | Applied => Closed |
