1) What do the chile process 'looked like' after fork
e.g. (using virtual memory address)
"Parent process":
- code memory address: 0x1000-0x2000
- data memory address: 0x2000-0x3000
after fork, is this what the child process looked like:
"Child process":
- code memory address: 0x3000-0x4000
- data memory address: 0x4000-0x5000
or?
- code memory address: 0x1000-0x2000 (same as parent)
- data memory address: 0x3000-0x4000

2) so do the OS do "rebasing" (just like loading a DLL in Win32 where
the 'desired' memory address is not available) of the child process
because the change in the memory address?

3) In case the child got it's new Code Memory, do some OS (vfork in
*nix???) map the virtual memory address of the code memory to the SAME
physical address?

I hope I'm asking questions that make sense.

Thank you

Baron

[ Post a follow-up to this message ]

baronng@astri.org (Baron) writes:
quote:

> 1) What do the chile process 'looked like' after fork
> e.g. (using virtual memory address)
> "Parent process":
> - code memory address: 0x1000-0x2000
> - data memory address: 0x2000-0x3000
> after fork, is this what the child process looked like:
> "Child process":
> - code memory address: 0x3000-0x4000
> - data memory address: 0x4000-0x5000
> or?
> - code memory address: 0x1000-0x2000 (same as parent)
> - data memory address: 0x3000-0x4000


Neither.  Both code and data stay at the same address.
quote:

> 2) so do the OS do "rebasing" (just like loading a DLL in Win32 where
> the 'desired' memory address is not available) of the child process
> because the change in the memory address?


No.
quote:

> 3) In case the child got it's new Code Memory, do some OS (vfork in
> *nix???) map the virtual memory address of the code memory to the SAME
> physical address?


The fork() call duplicates the page tables and marks all of the
child's pages as copy on write.  This means that, initially, both code
and data are mapped to the same physical memory as in the parent.  If
a page is written to by the child, that page will be allocated a new
physical page to perform the write on.  Code is read-only, so it will
never be copied.  The virtual address space is never changed.

--
Måns Rullgård
mru@kth.se

[ Post a follow-up to this message ]

mru@kth.se (examnotes) writes:
quote:

>The fork() call duplicates the page tables and marks all of the
>child's pages as copy on write.  This means that, initially, both code
>and data are mapped to the same physical memory as in the parent.  If
>a page is written to by the child, that page will be allocated a new
>physical page to perform the write on.  Code is read-only, so it will
>never be copied.  The virtual address space is never changed.


Small correction: if the page is written to by *either the parent or
the child* ....


Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[ Post a follow-up to this message ]

mru@kth.se (Måns Rullgård) wrote in message news:<yw1xhdyrotme.fsf@ford.guide>...
quote:

> baronng@astri.org (Baron) writes:
> 
>
> Neither.  Both code and data stay at the same address.
> 
>
> No.
> 
>
> The fork() call duplicates the page tables and marks all of the
> child's pages as copy on write.  This means that, initially, both code
> and data are mapped to the same physical memory as in the parent.  If
> a page is written to by the child, that page will be allocated a new
> physical page to perform the write on.  Code is read-only, so it will
> never be copied.  The virtual address space is never changed.


Are you talking about the case of 'vfork' instead of the old/original
'fork' implementation?(i read from the faq of the newsgroup that vfork
works like what you said, so i'd like to know the original
implementation of fork)

thank you!

[ Post a follow-up to this message ]

baronng@astri.org (Baron) writes:
quote:

> mru@kth.se (Måns Rullgård) wrote in message news:<yw1xhdyrotme.fsf@ford.gu
ide>... 
>
> Are you talking about the case of 'vfork' instead of the old/original
> 'fork' implementation?(i read from the faq of the newsgroup that vfork
> works like what you said, so i'd like to know the original
> implementation of fork)


vfork doesn't even copy the page tables.  After a vfork, the child
must call exec or _exit.  The child is not allowed to change any data
before doing one of these.

--
Måns Rullgård
mru@kth.se

[ Post a follow-up to this message ]

> vfork doesn't even copy the page tables.  After a vfork, the child
quote:

> must call exec or _exit.  The child is not allowed to change any data
> before doing one of these.


Quoted from "Unix Programmer FAQ":
-----------------------the FAQ-------------------------
Some systems have a system call `vfork()', which was originally
designed as
a lower-overhead version of `fork()'. Since `fork()' involved copying
the
entire address space of the process, and was therefore quite
expensive, the
`vfork()' function was introduced (in 3.0BSD).
=============
So it seems that the 'old'/unimproved implementation of fork copy the
ENTIRE memory space (including the code memory) when doing 'fork'
in this case, do the OS 'rebase' the child?
=============

-----------------------Continue the FAQ-------------------------
The basic difference between the two is that when a new process is
created
with `vfork()', the parent process is temporarily suspended, and the
child
process borrows the parent's address space. This strange state of
affairs
continues until the child process either exits, or calls `execve()',
at
which point the parent process continues.
=============
So, copy-on-write is used in fork...
and vfork suspend the parent process...and if the child call execve,
it works like 'fork' and can call "_exit" to exit right away
=============

So....the whole Virtual Memory Address space is different for
different process?
What i mean is that, in the case of "fork" - 2 processes actually
using the same virtual memory address but different physical
address....(as you said: "Both code and data stay at the same
address")

This conflict with my previous OS knowledge that the page table is a
one-to-one mapping between the virtual address and the physicall
address in the ENTIRE OS instead of "per-process"

Thank you very much!

[ Post a follow-up to this message ]

On 2004-01-21, Baron <baronng@astri.org> wrote:
quote:
 
>
> Quoted from "Unix Programmer FAQ":
> -----------------------the FAQ-------------------------
> Some systems have a system call `vfork()', which was originally
> designed as
> a lower-overhead version of `fork()'. Since `fork()' involved copying
> the
> entire address space of the process, and was therefore quite
> expensive, the
> `vfork()' function was introduced (in 3.0BSD).
>=============
> So it seems that the 'old'/unimproved implementation of fork copy the
> ENTIRE memory space (including the code memory) when doing 'fork'
> in this case, do the OS 'rebase' the child?


Can't say for very old processors and very old OS. But if some OS wanted
to be multi-processed then it had to support fork and could not allow
'rebasing' of child.  Just think about it. OS can't know where all your
pointers are and can't adjust them to the new "base".

quote:

>=============
>
> -----------------------Continue the FAQ-------------------------
> The basic difference between the two is that when a new process is
> created
> with `vfork()', the parent process is temporarily suspended, and the
> child
> process borrows the parent's address space. This strange state of
> affairs
> continues until the child process either exits, or calls `execve()',
> at
> which point the parent process continues.
>=============
> So, copy-on-write is used in fork...
> and vfork suspend the parent process...and if the child call execve,
> it works like 'fork' and can call "_exit" to exit right away


All the FAQ is trying to say is: Untill child is there parent can't run.
This avoids race conditions when child and parent update the same
physical memory. After child does exec or exit ('exit' would be really
stupid in this case, why to vfork and then just exit?) the parent can
continue working. So there's no copy-on-write here. And vfork does not
work like fork in this case. Maybe it would be simpler to think of
'fork' as a mean to allow independent actions on the memory content of
parent and 'vfork' as a mean to launch completely different process.
quote:

>=============
>
> So....the whole Virtual Memory Address space is different for
> different process?

quote:

> What i mean is that, in the case of "fork" - 2 processes actually
> using the same virtual memory address but different physical
> address....(as you said: "Both code and data stay at the same
> address")


Please, you contradict yourself. Virtual Memory Address space of child
and parent is the same. It can't be different  More than that, most of
the time any process has the same address for beginning of code,
for beginning of data and for the beginning of stack.
quote:

>
> This conflict with my previous OS knowledge that the page table is a
> one-to-one mapping between the virtual address and the physicall
> address in the ENTIRE OS instead of "per-process"


I don't think there was ever one-to-one mapping between virtual address
and physical address in OS that supported multiple processes.

DOS could afford it, but DOS didn't do fork.

Andrei

[ Post a follow-up to this message ]

Andrei Voropaev <avorop@mail.ru> writes:
quote:
 
>
> All the FAQ is trying to say is: Untill child is there parent can't run.


Rather, until the child has exec'ed or exited the parent can't run.
quote:

> This avoids race conditions when child and parent update the same
> physical memory. After child does exec or exit ('exit' would be really
> stupid in this case, why to vfork and then just exit?)


If an exec fails _exit is the proper thing to do.  Note that exit() is
forbidden after a vfork, since exit() does all sorts of cleanup, like
calling atexit() handlers etc.  _exit() exits immediately.
quote:

> the parent can continue working. So there's no copy-on-write
> here. And vfork does not work like fork in this case. Maybe it would
> be simpler to think of 'fork' as a mean to allow independent actions
> on the memory content of parent and 'vfork' as a mean to launch
> completely different process.


Correct.

--
Måns Rullgård
mru@kth.se

[ Post a follow-up to this message ]

baronng@astri.org (Baron) writes:
quote:

>=============
>So it seems that the 'old'/unimproved implementation of fork copy the
>ENTIRE memory space (including the code memory) when doing 'fork'
>in this case, do the OS 'rebase' the child?
>=============


There was a bug in VAX microcode that made it so that the
Copy-On-Write code couldn't be made to work; so they came up
with "vfork()" becaus efork() with "copy eveything" was
horribly expensive.

But even now, vfork() is O(1) and fork() is O(n) where
n is the number of pages in the process' address space.
quote:

>=============
>So, copy-on-write is used in fork...
>and vfork suspend the parent process...and if the child call execve,
>it works like 'fork' and can call "_exit" to exit right away
>=============


Even in a child of fork() it's almost always wrong to call exit().
quote:

>So....the whole Virtual Memory Address space is different for
>different process?


The virtual addresses are all the same and the physical address
are mostly the same, except where modified by COW (some stack
pages get dirtied immediately, of course)
quote:

>What i mean is that, in the case of "fork" - 2 processes actually
>using the same virtual memory address but different physical
>address....(as you said: "Both code and data stay at the same
>address")


Same virtual, same physical unless COW.
quote:

>This conflict with my previous OS knowledge that the page table is a
>one-to-one mapping between the virtual address and the physicall
>address in the ENTIRE OS instead of "per-process"


virtual to physical is a many to one mapping.

(Many virtual addresses map to the same physical address, e.g.,
ins shared libraries are text segments)

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[ Post a follow-up to this message ]

Måns Rullgård <mru@kth.se> spoke thus:
quote:

> The fork() call duplicates the page tables and marks all of the
> child's pages as copy on write.  This means that, initially, both code
> and data are mapped to the same physical memory as in the parent.  If
> a page is written to by the child, that page will be allocated a new
> physical page to perform the write on.  Code is read-only, so it will
> never be copied.  The virtual address space is never changed.


Is this true of all *nix flavors?  I know it's the case with Linux.
Just wondering.

--
Christopher Benson-Manica  | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org    | don't, I need to know.  Flames welcome.

[ Post a follow-up to this message ]