Please read my post earlier on the thread "When a parent process dies...".
The clarification below are additions to that post.
The contract for Sys_Kill is that it terminates the execution of the
process whose kill request it receives. It does not state that the process
needs to be removed from the system immediately. Bookkeeping in the kernel
and/or faults in the parents behaviour may cause it to hang around.
So its responsibility when killing the thread is to inform other threads
, waiting on it, of its demise and to terminate the killed threads
execution.
Now, considering the scenarios that you mention:
| 1) A process is spawned that spawns a foreground process and waits on
| that process. In other words, the behavior of create_child.c. A user
| then calls kill on the child process.
This is the simple scenario. The child gets killed and the parent gets
woken up. refCount will be zero when the parent gets the exitcode from the
child.
| 2) A process is spawned that spawns a foreground process and DOES NOT
| wait on that process. Similar to create_child.c except that the parent
| does not wait on the child. A user then calls kill on the child process.
Here, killing the child (and removing its selfreference) will only lead to
one decrement of the refCount and the child would end up being a zombie
with a reference from the parent still there. Note the child would not be
executing at this point either. This _is_ the behaviour that is expected.
To completely remove the thread, another Kill request would have to be
sent to release the refCount from the parent; who failed to Wait for the
child.
| The point is, if kill chooses only to decrement refCount by 1 and wake
| the parent it does not fulfill its contract of removing the process from
| the system because it relies on the parent calling Wait. If the parent
| is not calling Wait then kill creates a zombie process and fails to
| remove the thread from the system.
thats ok. removing the thread from the system was never the intention of
Sys_Kill anyway. Just termination of execution.
| However, if we choose to zero the refCount manually and kill the process
| there is another problem. Presumably we want to wake the parent that
| had previously been waiting for the process we just killed. When this
| parent wakes up it will be in the middle of a Join call with a
| Kernel_Thread reference to an invalid (dead) thread, at which point it
| will access possibly deallocated memory.
|
| The latter situation seems to be more desirable than the former since
| kill then fulfills its contract. However, what should the behavior of
| Join be upon waking up with an invalid Kernel_Thread pointer.
|
| Alternatively, we could simply fail to wake the parent thread to avoid
| the problem entirely. This seems like a rather silly policy though.
| Please clarify.
If we understand that a Kill is not a complete purge then we do not even
need to think about these hacks.