3

I've managed to question myself about the wait(2) and _exit(2) system calls in a process lifecycle.

My question about the wait(2) system call is... does the parent process issue it to the kernel? Or does the kernel issue it to the parent process? And is the [_exit(2)] system call issue from the child process to the parent process? Or does the child process issue the [_exit(2)] to the kernel?

I tried googling and watching youtube videos for the answer... But I never saw anything specific to this.

Improve this question

1 Answer 1

Reset to default
6

System calls are always made by processes to the kernel.

So to answer the specific questions.

  1. The parent process makes the wait call to the kernel.
  2. The child process makes the exit call to the kernel.

The following is a much simplified view of what happens.

When the process calls exit the kernel stores the argument (the return code) in the internal process table, destroys all the other resources associated with the process (allocated memory, open file descriptors) and marks the process as a zombie.

When the parent calls wait the kernel checks to see if any child is in zombie state. If so then it gets the stored return code from the internal process table, releases the slot in the table and returns from the wait system call passing back the return code. If the child is not in zombie state then the kernel blocks the parent process until the child calls exit.

When any process calls exit then any remaining child processes are reparented to the process with PID 1, so all processes except the first always have a parent.

PID 1 starts everything running (network services, listeners on serial lines, the gui login program), and then goes into an infinite loop calling wait so the kernel process table doesn't fill up with zombies.

There are a lot of things I have simplified, these days you can ask the kernel to reparent to a process other than process number 1 a subreaper, there are lots of forms of the wait call (wait, waitid, waitpid, wait3, wait4 (man pages), interaction with the ptrace system call, what destroying the allocated resources means etc.

Improve this answer
2
  • 2
    Another mechanism is available. Whenever a process exits, the kernel sends a SIGCHLD signal to the parent. The default action is for the parent to ignore this. However, the parent can choose to provide a signal handler for SIGCHLD, and reap the exit status of each child when it first becomes available. This allows the parent not to suspend itself on a wait if it has more useful work to do. Commented Feb 17, 2020 at 18:23
  • @Paul_Pedant 2 points. First I did say I was simplifying! Second the SIGCHLD just notifies the parent process, the parent still needs to call one of the wait variants to get the return code etc. What you can and can not do in a signal handler is interesting in its own right. I happen to like the stuff covered by unix.stackexchange.com/questions/531171/… Commented Feb 17, 2020 at 20:09

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.