Control flow of fork system call when wait is present or not present

In this code (run on linux):

void child_process()
{
    int count=0;

    for(;count<1000;count++)
    {
        printf("Child Process: %04d\n",count);
    }
    printf("Child's process id: %d\n",getpid());
}

void parent_process()
{
    int count=0;

    for(;count<1000;count++)
    {
        printf("Parent Process: %04d\n",count);
    }
}


int main()
{
    pid_t pid;
    int   status;        

    if((pid = fork()) < 0)
    {
        printf("unable to create child process\n");
        exit(1);
    }
    
    if(pid == 0)
        child_process();
    

    if(pid > 0)
    {
        printf("Return value of wait: %d\n",wait();
        parent_process();
    }

    return 0;
}

If the wait() were not present in the code, one of the process (child or parent) would finish it's execution and then the control is given to the linux terminal and then finally the process left (child or parent) would run. The output of such a case is:

Parent Process: 0998
Parent Process: 0999
guest@debian:~/c$ Child Process: 0645   //Control given to terminal & then child process is again picked for processing
Child Process: 0646
Child Process: 0647

In case wait() is present in the code, what should be the flow of execution?

When fork() is called then a process tree must be created containing parent and child process. In above code when the processing of child process ends, the parent is informed about the death of child zombie process via wait() system call, but parent and child being two separate processes, is it mandatory that the control is passed the directly to the parent after child process is over? (no control given to other process like terminal at all) - if yes then it is like child process is a part of parent process (like a function called from another function).

Solution

This comment is, at least, misleading:

   //Control given to terminal & then child process is again picked for processing

The "terminal" process doesn't really enter into the equation. It's always running, assuming that you are using a terminal emulator to interact with your program. (If you're using the console, then there is no terminal process. But that's unlikely these days.)

The process in control of the user interface is whatever shell you're using. You type some command-line like

$ ./a.out

and the shell arranges for your program to run. (The shell is an ordinary user program without special privileges, by the way. You could write your own.)

Specifically, the shell:

Uses fork to create a child process.
Uses waitpid to wait for that child process to finish.

The child process sets up any necessary redirects and then uses some exec system call, typically execve, to replace itself with the ./a.out program, passing execve (or whatever) the command line arguments you specified.

That's it.

Your program, in ./a.out, uses fork to create a child and then possibly waits for the child to finish before terminating. As soon as your parent process terminates, the shell's waitpid() can return, and as soon as it returns, the shell prints a new command prompt.

So there are at least three relevant processes: the shell, your parent process, and your child process. In the absence of synchronisation functions like waitpid(), there are no guarantees about ordering. So when your parent process calls fork(), the created child could start executing immediately. Or not. If it does start executing immediately, it does not necessarily preempt your parent process, assuming your computer is reasonably modern and has more than one core. They could both be executing at the same time. But that's not going to last very long because your parent process will either immediately call exit or immediately call wait.

When a process calls wait (or waitpid), it is suspended and becomes runnable again when the process it is waiting for terminates. But again there are no guarantees. The mere fact that a process is runnable doesn't mean that it will immediately start running. But generally, in the absence of high load, the operating system will start running it pretty soon. Again, it might be running at the same time as another process, such as your child process (if your parent didn't wait for it to finish).

In short, if you performed your experiment a million times, and your parent waits for your child, then you will see the same result a million times; the child must finish before the parent is unsuspended, and your parent must finish before the shell is unsuspended. (If your parent process printed something before waiting, you would see different results; the parent and child outputs could be in any order, or even overlapped.)

If, on the other hand, your parent does not wait for the child, then you could see any of a number of results, and in a million repetitions you're likely to see more than one of them (but not with the same probability). Since there is no synchronisation between parent and child, the outputs could appear in either order (or be interleaved). And since the child is not synchronised with the shell, its output could appear before or after the shell's prompt, or be interleaved with the shell's prompt. No guarantees, other than that the shell will not resume until your parent is done.

Note that the terminal emulator, which is a completely independent process, is runnable the entire time. It owns a pseudo-terminal ("pty") which is how it emulates a terminal. The pseudo-terminal is a kind of pipe; at one end of the pipe is the process which thinks it's communicating with a console, and at the other end is the terminal emulator which interprets whatever is being written to the pty in order to render it in the GUI, and which sends any keystrokes it receives, suitably modified as a character stream back through the pipe. Since the terminal emulator is never suspended and its execution is therefore interleaved with whatever other processes are active on your computer, it will (more or less) immediately show you any output which is sent by your shell or the processes it starts up. (Again, assuming the machine is not overloaded.)