Handling the children of the process that is killed

[c***@CSIC.UMD.EDU]

So the way we are
implementing
background in this
project will ensure
when a thread is
spawned it will
always have a valid
owner reference.

However, say if you
killed the parent
process. Do you
update the owner
reference of its
children ? if you
set them to zero as
in p1, the children
of the process to be
killed will no
longer have a valid
owner reference,
hence when the
children die they
will not be able to
send the sigchild
signal to their
parent as the parent
wont exist

and if do you do not
set the owner to 0,
the parent will die
anyways but the
refcount of children
will remain 2 and
when they die they
will decrement their
refCount but again
the sigchild signal
to the parent will
fail. As a result
they will remain as
zombies in the
system.

Any help on this
would be
appreciated.

[David Marcin]

Why not update the parent pointer to be 0 (since it doesn't have a
parent) and only send a sigchld if refcount is 2 when it dies?

Alternatively, since a PID of 0 should not exist, sending it a signal
should, in theory, be ignored and do absolutely nothing. This is
similar to when we tried to kill processes that didn't exist last
project, we just returned an error code.

[c***@CSIC.UMD.EDU]

yes, but the question would be which approach to take as they might lead to
different results while testing.

[Daniel Ramsbrock]

Along these same lines, what happens if the parent process simply exits
and one or more attached children are still running? This is entirely
legal now that WaitNoPID exists and the parent is no longer required to
Wait() on its children individually. I assume we should not be modifying
Exit() to look for all possible children and reset their parent
pointers...these children would simply become zombies upon exit (just as
was the case in project 1 when a parent failed to Wait() on its children
and exited before they did). Is that assumption correct?

Daniel

Post by c***@CSIC.UMD.EDU
However, say if you
killed the parent
process. Do you
update the owner
reference of its
children ?

[Saurabh Srivastava]

The behaviour on the exit (or killing) of the parent has to be such that
we maintain consistent state in the system. In the current requirements
each process (fg _or_ bg) has a reference from the parent which
contributes to its refCount. If the parent dies in whatever manner then
the refCount of the child should come down. It should also result in the
owner field of any children being set to NULL.

So essentially this is what happens: On killing or exit you will need to
find all children and update their fields (owner/refCount) appropriately.
Unless the child itself is dead.

On exit in the child, if it contains a valid owner then you send a SIGCHLD
to the parent or else just dont do anything. This prevents signals being
sent to nonexistant PIDs.



On Thu, 29 Sep 2005, Daniel Ramsbrock wrote:

| Along these same lines, what happens if the parent process simply exits
| and one or more attached children are still running? This is entirely
| legal now that WaitNoPID exists and the parent is no longer required to
| Wait() on its children individually. I assume we should not be modifying
| Exit() to look for all possible children and reset their parent
| pointers...these children would simply become zombies upon exit (just as
| was the case in project 1 when a parent failed to Wait() on its children
| and exited before they did). Is that assumption correct?
|
| Daniel
|
| ***@CSIC.UMD.EDU wrote:
| > However, say if you
| > killed the parent
| > process. Do you
| > update the owner
| > reference of its
| > children ?
|

[David Marcin]

Post by Saurabh Srivastava
So essentially this is what happens: On killing or exit you will need to
find all children and update their fields (owner/refCount) appropriately.
Unless the child itself is dead.
No. I am of the opinion that if the user level code does not conform
to the semantics of spawning foreground processes then the creation of
zombies is expected. The only way to get them cleaned out of the
system would be to use our newfound ability to Sys_Kill them. :)

Why the sudden change of heart? Why do we penalize kernel efficiency for
user processes that fail to wait on their children in this project but not
in the last project? At this stage of the project I think it's only fair
to grade either way, some of us can't work on this before 6PM tonight.

[Saurabh Srivastava]

I agree that this is inconsistent in the light of both background and
foreground processes. I only had backgrounded processes in mind when I was
writing this. A background process now has a reference and we would want
to clean up that reference on the parent's exit. This was not the case
earlier; bg child processes were treated differently back then and so it
wasnt a problem when we exited the parent.

As for fg children, I still think it is ok for them to be zombies if the
parent doesnt do as required. But then, what I wrote about traversing for
_any_ child process and clearing them up is in contradiction with my
statements earlier, I admit. (because these includes fg processes in
addition to bg ones, a fact that I ignored). Again, as I noted, this is
`my opinion' and people might disagree.

As for the grading, I'm certain both implementations can be accomodated.
(As a sidenote, it appears that this difference would not be tested
anyway, given the current grading criterion).

-

| Saurabh Srivastava wrote:
| > So essentially this is what happens: On killing or exit you will need to
| > find all children and update their fields (owner/refCount) appropriately.
| > Unless the child itself is dead.
|
| Wait a sec, last project you said this on the topic of cleaning up on Exit():
| > No. I am of the opinion that if the user level code does not conform
| > to the semantics of spawning foreground processes then the creation of
| > zombies is expected. The only way to get them cleaned out of the
| > system would be to use our newfound ability to Sys_Kill them. :)
|
| Why the sudden change of heart? Why do we penalize kernel efficiency for
| user processes that fail to wait on their children in this project but not
| in the last project? At this stage of the project I think it's only fair
| to grade either way, some of us can't work on this before 6PM tonight.