fork behaviour......what is the output of this program
 

What is the output of the program?
i expected output to be something like this
In Child 8990
In Parent 8988
but it is changing every time when i compile. Why fork behave like this.
See the code and output
-------------------------------------------------------------------
#include<stdio.h>
main()
{
int pid;
pid = fork();
if(pid==0)
{
printf("In Child %d\n",getpid());
}
else
{
printf("In Parent %d\n",getpid());
}
}
-------------------------------------------------------------------
[rgv@rajguruvin ~]$ vi fork.c
[rgv@rajguruvin ~]$ gcc fork.c
[rgv@rajguruvin ~]$ ./a.out
In Child 17520
In Parent 17519
[rgv@rajguruvin ~]$ ./a.out
In Parent 17521
In Child 17522
[rgv@rajguruvin ~]$ ./a.out
In Child 17524
In Parent 17523
[rgv@rajguruvin ~]$ ./a.out
In Parent 17525
In Child 17526
[rgv@rajguruvin ~]$ ./a.out
In Parent 17525
In Child 17526

I am using fedora 12.vim editor,gnome,2.6.31.5-127.fc12.i686.PAE


why fork behaves like this..
Is this problem with fedora or any other.

Seriously?

The process ID's are changing every time, because you're getting a new process ID every time. Kind of like saying "I'm using a random number generator, and I'm getting a different number every time! What's wrong?!?!"

Maybe I don't understand the question.

You're telling it to fork (start a new process) then print the Process Identifier (PID) of the new process. Every new process gets a new PID so what you're seeing is expected behavior. PIDs do get reused over time but not immediately so if one PID goes away you'll get the next in sequence not the same one when you start a new process even if it is the same code.

I am not telling about process ID
the calling of child process and parent process getting differed? why?

LOOK at the output, the calling of child process and parent process is different by the fork .. why?
----------------
[rgv@rajguruvin ~]$ ./a.out
In Child 17520
In Parent 17519
[rgv@rajguruvin ~]$ ./a.out
In Parent 17521
In Child 17522
------------------

The fact your seeing both the if and the else output (Parent and Child) suggests your conditional is poorly formed as a true conditional should only return one or the other.

Maybe the lack of a space between the "if" and the opening parentheses?

As to why they seem to be printing asynchronously that is probably just a matter of how fast the system loads and executes each printf but as noted above that isn't your real problem with this.

1) The answer to your other thread is simpler. BTW I think Tinkster
was wrong to just close that thread, because the question you asked there is not the same as you asked here. (But moderators may not have time to read that carefully, so don't start two threads that look like the same question)
http://www.linuxquestions.org/questi...rogram-818313/

When you do a fork, the process is duplicated except for the tiny difference that is documented behavior of fork.

When you do a printf without a \n in it, the output is typically buffered inside your process rather than actually written to the standard output (it is written later).

Combining those two facts, you can understand why the first "Hello" came out twice. It was buffered by the single execution of printf that wrote it. Then the buffer was duplicated with the rest of the process by fork. Then when each buffer was flushed that output appeared.

2) In what sequence do the two processes reach the \n in their respective printf's? (The \n being the trigger for actual output of everything buffered to that point).

The simple answer is that fork provides no promise about that sequence. They are two independent processes at the same priority and either is equally likely to get the next time slice. In theory it is random.

But there is no actual randomness intentionally applied to this decision. You expect a computer to be deterministic even when the choice between two behaviors isn't specified by the standard. Where is the actual source of randomness that makes the results vary?

Obviously, the CPU use of anything else that might be running on your computer at the same time could affect the scheduler to be the source of such differences. But on a lightly loaded single user system that tends not to be the cause. The relative timing of the triggering keystroke vs. the periodic timer interrupts could also be the root cause of the difference.

One would need an extreme knowledge of the internals of Linux (as well as details of your particular system) to even make an educated guess about which source of difference causes your deterministic computer to produce these non deterministic looking results.

The bottom line is that OS's are complicated enough that you should expect them to seem non deterministic on this kind of choice.

You're missing the point of the fork. There are two different processes after the fork and each takes one of the two paths through the if.

Yes, you are. Like right here in YOUR CODE
See the "getpid"?? What, exactly, do you think that does?

Fork is a system call. That means the execution traps into the kernel. It makes a copy of the process that made the call. Now two things might happen the parent process may be running till pre-empted by the clock and child will be waiting(The case where Parent prints first). Or the scheduler will be called and may be child will get a chance to execute (The case where child gets to print first).
Whether scheduler is always called after fork is a linux specific issue. But you understand that which process gets to print first is a matter of chance.
If you would like to achieve strict ordering there are other ways such as blocking and waiting loops etc.

Regards.

hi,

be careful with fork. It is very easily to write some a kind 'virus' using 'fork'.
A process which does only one thing - replicate itself -
so in 10 sec you may have 2^100 processes and your system won't respond,

I tried this book "Interprocess communications in Unix" by John Shapley Gray, sec.ed.
Nice written. Very good, an easy to understand explanation what the 'fork' really is.
All program sources from the book I checked on my slack 12.2 - Linux kernel 2.6.27..
In the book you also find what are pipes, sockets and ipc -
standard UNIX process communication architecture.
I guess no longer natively supported with kernels 2.6.x. But there is an implementation. So, have fun :-)