On Mon, Jan 11, 2010 at 3:01 PM, Pete <greg.petr@xxxxxxxxx> wrote:
>
>> On Mon, Jan 11, 2010 at 6:22 AM, Mulyadi Santosa
>> <mulyadi.santosa@xxxxxxxxx> wrote:
>> > On 1/11/10, Joel Fernandes <agnel.joel@xxxxxxxxx> wrote:
>> >> Oh I'm sorry, if you were talking about copying of the address space
>> >> information that can be avoided, that does not happen because it
>> >> would've already been copied before exec() in the child gets a chance
>> >> to execute.. the fork system call calls do_fork somewhere which calls
>> >> copy_process which does this copying so it can't be avoided in any
>> >> case. The book says copy-on-write itself has more overhead that is
>> >> avoided with exec() in the child, but I'm trying to figure how.
>> >>
>> >> -Joel
>> >
>> >
>> > Hi Joel...
>> >
>> > Manish is right. Please notice that he talked about "why do we do copy
>> > on write (COW) if soon after child is forked, it quickly does exec()".
>> > So yes, COW has overhead, but imagine if parent ran first. COW will be
>> > triggered for parent address space, then child soon runs too. Then it
>> > issues exec(). Clearly, this waste certain amout of memory which can
>> > be fairly avoided if child runs first.
>
>
> After going through this thread, I just tried out the following simple
> code:
>
> int main (void) {
>
> int pid;
>
> int *testVar = (int *) malloc (sizeof (int));
>
> *testVar = 10;
>
> printf ("%d [%d] Main \n", *testVar, testVar);
>
> pid=vfork(); // works fine if we use fork instead.
>
> if (pid==0) {
>
> printf ("Child %d [%d]\n", *testVar, testVar);
>
> return 1;
>
> } else if (pid > 0) {
>
> printf ("Parent %d [%d]\n", *testVar, testVar);
>
> *testVar=11; // segfault if we use vfork, as vfork blocks until child
> returns call exec/exits.
>
> wait(NULL);
>
> printf ("Parent %d [%d]\n", *testVar, testVar);
>
> return 1;
>
> }
>
> exit(0);
> }
>
> can someone let me know why this segfaults with vfork and not with fork?
Man page says most of the stuff :-
"
The use of vfork() was tricky: for example, not modifying data
in the parent process depended on knowing which variables are held in
a register.
In particular, the programmer cannot rely on the parent remaining blocked
until the child either terminates or calls execve(2), and cannot
rely on any specific behavior with respect to shared memory.
"
Thanks -
Manish
> >From my understanding - it is because the parent is blocked until the
> child exec's/exits AND in the mean time when the program is being
> executed the child/parent process is trying to change the *testVar is
> causing to modify the parents read-only memory. CMIAW.
>
> Another thing I noticed is on linux the child always gets to run first
> in case of fork() and vfork()?
>
> Cheers
> ~Pete
>
>
>
> --
> To unsubscribe from this list: send an email with
> "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
> Please read the FAQ at http://kernelnewbies.org/FAQ
>
>
--
Thanks -
Manish
==================================
[$\*.^ -- I miss being one of them
==================================
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
