Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0001114 [1003.1(2016/18)/Issue7+TC2] System Interfaces Editorial Clarification Requested 2017-01-12 16:05 2024-06-11 09:09
Reporter Florian Weimer View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Florian Weimer
Organization Red Hat
User Reference
Section fork
Page Number unknown
Line Number unknown
Interp Status ---
Final Accepted Text Note: 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
Attached Files

- Relationships
related to 0001383Closed Issue 8 drafts Make "Application Usage" less confusing. 

-  Notes
(0003541)
torvald (reporter)
2017-01-12 16:50

 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.
(0004054)
geoffclare (manager)
2018-07-19 15:20

 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.
(0004055)
geoffclare (manager)
2018-07-19 15:22

 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.

- Issue History
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
2017-01-12 16:50 torvald Issue Monitored: torvald
2017-05-19 20:20 slow Issue Monitored: slow
2017-10-30 16:35 Florian Weimer Issue Monitored: Florian Weimer
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 => Note: 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

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