do parent and child process have same stack

http://www.steve.org.uk/Reference/Unix/faq_2.html

according to the above link开发者_开发技巧, the child gets a copy of the stack, memory etc from the parent. is that correct?

---

Your link is right. Memory is not shared by processes, only by threads in the same process (and even then, threads have their own stacks).

On modern Unices, however, the memory pages involved are usually copy-on-write: a copy is only made in the child process' address space when this process (or its parent) modifies one of those pages.

Therefore, the actual memory footprint of children processes can remain quite low, even if their parents consume a lot of space.

---

Just after a program calls fork(), the newly-created child process is identical (heap, stack, and even file handles). This is a fundamental part of how Unix works; it's how a program launched by your shell gets to write to the same terminal as the shell. The program doesn't know which xterm it's being run within; it just inherits its stdin and stdout file handles from its parent process.

For memory, this may seem like a bit of a waste, since fork() is usually followed by exec() to run a new program (again, as in the shell). However, how would the child program know which program to exec(), if it didn't have access to the data from before the point of fork()?

Furthermore, fork() predates threads and even more rudimentary forms of multiprocessing like select(). In olden days (provided you had enough memory), it was a common design to write a program that fork()ed several children to do I/O-heavy tasks. If one child process got temporarily hung up doing I/O, the others could still move along. The Apache web server worked like this in version 1.x.

As far as how the mechanics of the "copy" works, that's system dependent. Some (older) systems implement this is a full copy, but most (newer) systems implement it as copy-on-write. That is, at the point of fork(), both parent and child share the exact same pages of memory. When either the parent or child changes the contents of memory, whomever did the change gets a private copy of the changed memory (changes don't get shared); the other process keeps the "old" copy for himself. If all they do is read, no additional memory is used.

The copy-on-write mechanism is completely transparent to the program. The virtual memory subsystem does all that behind the scenes; even memory addresses don't change.

---

From the article you linked to:

Of help when doing this is knowing just what is and is not inherited by the child. [...] Note that the child gets copies of these things, not the real thing:

• [...]
• stack
• [...]

I'm a little fuzzy on it, but I think processes get their own memory stuffs; that's what makes them different from threads which share all that stuff.

From the Wikipedia article on Threads:

Multiple threads can exist within the same process and share resources such as memory, while different processes do not share these resources.