Hi,
When a process forks, every resource of the parent, including the
virtual memory is copied to the child process. The copying of VM uses
copy-on-write(COW). I know that COW comes when a write request comes,
and then the copy is made. Now my query follows:
How will the copy be distributed. Whether giving the child process a new
copy of VM be permanent or whether they will be merged anywhere? And
shouldn't the operations/updations by one process be visible to the
other which inherited the copy of the same VM?
How can this work? Can someone please help me on this regard?
--
With regards,
Jagadeesh Bhaskar P
R&D Engineer
HCL Infosystems Ltd
Pondicherry
INDIA
On Sat, 20 Nov 2004 16:08:21 +0530, Jagadeesh Bhaskar P
<[email protected]> wrote:
> Hi,
>
> When a process forks, every resource of the parent, including the
> virtual memory is copied to the child process. The copying of VM uses
> copy-on-write(COW). I know that COW comes when a write request comes,
> and then the copy is made. Now my query follows:
>
> How will the copy be distributed. Whether giving the child process a new
> copy of VM be permanent or whether they will be merged anywhere? And
Permanent. Re-merging (or rather call it UN-COWING ;) is not
considered necesary.
> shouldn't the operations/updations by one process be visible to the
> other which inherited the copy of the same VM?
No, because by default all allocations are marked as private for each
process. The fact is, the original UNIX did not do COW, but did copy
the whole process memory and handed this copy to the child process.
> How can this work? Can someone please help me on this regard?
If you want to share a mapping, the easiest way is to:
1. Create a temp file on /tmp with the size you need.
2. mmap the file, which will get the file contents into your
addressing space. Remeber to ask for shared mapping.
3. Fork.
4. Now both processes have an mmaped file with shared mapping.
Anything written by one is seen by the other, since they use the same
backing space. The contents are also visible by doing a cat on the
shared temporary file (this is great for debugging :).
You may not want to keep the file around. You can delete the file just
after having opened it, so that it's not visible on the filesystem. It
will just keep using the space until you exit all processes which were
using the file.
--
Greetz, Antonio Vargas aka winden of network
Las cosas no son lo que parecen, excepto cuando parecen lo que si son.
Jagadeesh Bhaskar P wrote:
>Hi,
>
> When a process forks, every resource of the parent, including the
>virtual memory is copied to the child process. The copying of VM uses
>copy-on-write(COW). I know that COW comes when a write request comes,
>and then the copy is made. Now my query follows:
>
>How will the copy be distributed. Whether giving the child process a new
>copy of VM be permanent or whether they will be merged anywhere? And
>
>
Merging can only happen if the two pages becomes equal
again. That is extremely unlikely, and checking for this
would cost a lot more than the memory saved.
>shouldn't the operations/updations by one process be visible to the
>other which inherited the copy of the same VM?
>
>
Of course not - the whole reason for copying is so such
modifications won't be visible for the other process.
There may be special cases (shared mapping) where one
process is supposed to see updates done by another - but
then no COW is performed because there is no need.
Helge Hafting
Jagadeesh Bhaskar P wrote:
> Hi,
>
> When a process forks, every resource of the parent, including the
> virtual memory is copied to the child process. The copying of VM uses
> copy-on-write(COW). I know that COW comes when a write request comes,
> and then the copy is made. Now my query follows:
>
> How will the copy be distributed. Whether giving the child process a new
> copy of VM be permanent or whether they will be merged anywhere? And
> shouldn't the operations/updations by one process be visible to the
> other which inherited the copy of the same VM?
The copies are separate and distinct, and the whole concept of the fork
is to have an independent process. Operations are (deliberately) not
visible from one process to another, that need can be met by the
shmget/shmat system calls (share on swap), mmap call (share on
filesystem), or by just using threads instead of fork. There may be
performance hits one way or the other, on large systems swap may be
faster than a filesystem, particularly /tmp if you use that.
>
> How can this work? Can someone please help me on this regard?
>
Man pages on shmget and mmap will get you started.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me