|
Home > Archive > Unix Programming > February 2005 > child process and fork()
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
child process and fork()
|
|
| ramsin.savra@gmail.com 2005-02-14, 5:55 pm |
|
Hello all,
The book "Beginning Linux programming" written by Neil Matthew and
Richard Stones;
says that "when a child process terminates, an association with its
parent survives until the parent terminates normally or calls wait. the
child process is still in the system because its exit code needs to be
stored in case the parent subsequently calls wait. "
question:
why a child process' exit code which is terminated should be stored?
also why there is a case (as it says above) that parent calls wait
again when the child doesn't exist?
can you please explain it to me if you get a chance.
Thanks,
Ramsin
| |
| Rich Teer 2005-02-14, 5:55 pm |
| On Mon, 14 Feb 2005 ramsin.savra@gmail.com wrote:
> The book "Beginning Linux programming" written by Neil Matthew and
> Richard Stones;
> says that "when a child process terminates, an association with its
> parent survives until the parent terminates normally or calls wait. the
> child process is still in the system because its exit code needs to be
> stored in case the parent subsequently calls wait. "
>
> question:
> why a child process' exit code which is terminated should be stored?
It's the only way to get the child's exit status.
> also why there is a case (as it says above) that parent calls wait
> again when the child doesn't exist?
The parent might not call wait until after the child has died (e.g.,
from inside an SIGCHLD handler).
--
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming"
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
| |
| David Schwartz 2005-02-14, 5:55 pm |
|
<ramsin.savra@gmail.com> wrote in message
news:1108420274.073795.263020@z14g2000cwz.googlegroups.com...
> The book "Beginning Linux programming" written by Neil Matthew and
> Richard Stones;
> says that "when a child process terminates, an association with its
> parent survives until the parent terminates normally or calls wait. the
> child process is still in the system because its exit code needs to be
> stored in case the parent subsequently calls wait. "
>
> question:
> why a child process' exit code which is terminated should be stored?
Think about it logically. The parent knows the child's PID and can pass
this to a wait function to get the return code. If the child terminates, the
system must be sure not to assign that PID to another process (otherwise,
how would it know which process the parent is waiting for). The easiest way
to make sure the PID is not reassigned, and to have a place to keep the exit
status, is to keep an entry in the process table.
> also why there is a case (as it says above) that parent calls wait
> again when the child doesn't exist?
You can't get the child's exit status until the child process has
terminated. So the normal case is that you call one of the wait functions to
get the child's exit status after the child process has already terminated.
However, for the reasons I explained above, the child process still exists.
It still exists for the sole purpose of preventing its PID from being reused
and to provide a place for the exit status to be stored.
DS
| |
| SM Ryan 2005-02-15, 8:06 am |
| ramsin.savra@gmail.com wrote:
#
# Hello all,
#
# The book "Beginning Linux programming" written by Neil Matthew and
# Richard Stones;
# says that "when a child process terminates, an association with its
# parent survives until the parent terminates normally or calls wait. the
# child process is still in the system because its exit code needs to be
# stored in case the parent subsequently calls wait. "
#
# question:
# why a child process' exit code which is terminated should be stored?
#
# also why there is a case (as it says above) that parent calls wait
# again when the child doesn't exist?
The sentences are perhaps a bit hard to parse;
The statement
when a child process terminates, an association with its
parent survives until the parent terminates normally or calls wait
describes the overall interaction. (Actually if the parent exits without wait,
the child is adopted by init, and init reaps its exit code.)
The statement
the child process is still in the system because its exit code needs to be
stored in case the parent subsequently calls wait
explains why a child may become a zombie. The 'subsequently calls' does not mean
'repeated calls', but rather 'makes the one call I referred to in the preceding
sentence.'
--
SM Ryan http://www.rawbw.com/~wyrmwif/
Don't say anything. Especially you.
|
|
|
|
|