Austin Group Defect Tracker

Aardvark Mark III

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

- Relationships

-  Notes
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.

- 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

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