简体   繁体   中英

Parent and child of fork() in C

Since each process is doing its own thing, which to me feels more like a "brothers/sisters" relationship. Is there a specific reason behind calling them parent process and child process?

Also, is it true that the parent process always run before the child process?

The parent owns the process group and thus spawns and reaps the children. Usually this process does a little bit of administrative work, while the children act as peers and siblings.

The naming is just convention for describing which process spawned the other, though.

The parent process and child process does the work based on your code but not because of parent or child relationship. When you execute fork() in the main thread it will create a child process, here the fork returns a value which is different in parent process and child process which can be used to differentiate the work of parent and child processes accordingly. fork() always return pid of child in parent process and 0 in child process.

Coming to your second question it always depends on the scheduler as soon as the fork() is called and we cannot predict which process gets to run first after fork() function call.

Is there a specific reason behind calling them parent process and child process?

Well, since it one process (the parent) that creates the second one (the child), that might be the reasoning for the naming.

Also, is it true that the parent process always run before the child process?

The short answer. Nope. I have been using this in all of my C-code

pid_t pid = fork();
  if(pid == 0){ // child     
    // Child stuff
  }else{ // parent
    // Parent stuff
}

You might also want to use the

waitpid(pid, NULL, 0);

fork() creates a copy of the current process which is a part of the process control group. The new process is subordinate to the originating process, for example when a child process dies, SIGCHLD is sent to the parent. Also, the clone is an inferior copy: for instance, any stored getpid() results will be inaccurate in the child; the child has a different parentid , the child has copies of the parent's file descriptors, and has independent resource usage counters.

The parent process, then, is always the one that made the call to fork() , if that's what you mean by run first. If you mean "will the scheduler always give the parent process slices first" then the answer is no.

See: http://gauss.ececs.uc.edu/Courses/c694/lectures/ForksThreads/forks.html , http://linux.die.net/man/2/fork

#include <stdio.h>
#include <unistd.h>

int main(int argc, const char* argv[])
{
    pid_t otherPid;

    printf("parent pid = %u\n", getpid());

    otherPid = fork();
    // in the parent, otherPid = the child's (new) process ID
    // in the child, otherPid = 0.

    switch (otherPid) {
        case -1:
            printf("Fork failed: %d\n", errno);
            return errno;
        break;
        case 0: // child
            sleep(2);
            printf("child: my pid is %u\n", getpid());
        break;
        default:
            printf("parent: pid is %u, child should have %u\n", getpid(), otherPid);
            sleep(3);
        break;
    }

    return 0;
}

Parents are always before child. Sort and sweet!!!

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM