The goal here was to effectively understand the difference between waiting, finishing and killing.
Waiting: When a process is waiting, it is silent, nothing happens, nothing is shown it is just waiting. On this occasion the silence does not give you any information, so you have to understand the language the system is speaking in order to understand what is happening. Do not assume what is happening if you are not sure, ask someone who knows or do research in order to avoid mistakes that can cost your company money. Here is why assuming the reason for silence is dangerous, silence means unresolved dependency, and unless you know what those dependencies are DO NOT ASSUME.
"Unresolved dependency" means make sure you are assuming correctly because the process may still be running and in this case on the cloud that means money is being spent…
It means a process is still running, a job is still being done that is why there is no information being displayed or nothing is happening because unless the process is over, and the job is done, it is still waiting.
So that is what waiting is.
Finishing is the fulfillment of the process function. Meaning, the process started, respected all the contract it had with the kernel and gave back to the user what the user assumed it would get. For example: cat dot.txt → should print the contents of dot.txt on the terminal and then the process is over. Or cat dot.txt → should give you an error if the file doesn’t exist.
Both these scenarios are the process completing its function and being done. And the only way for it to do that is to observe an EOF (CTRL+D) indication(sign) that says the door is closed and there would be no more data to be sent. At that moment, the process can move from waiting to finishing.
“EOF is an explicit indication that the input source is closed and no more data can arrive.”
Killing is the part where the process has no choice but to finish. Regardless of its function agreement, killing a process means stopping everything right now. And because of the contract between the program and the kernel, the process will be forced to be done without completing its function. One of the ways to kill a function is to send a signal (CTRL+C).
Here is a way of thinking about it by roles:
The user: the user role is to communicate with the process through the kernel to decide the progress of the process. And this is because the user is the one typing, stdin... So if the user understands the rules and the language of the system, they will understand that for the proper progress of the process we need to shut that door calmly and for that we need the process to observe EOF.
EOF : This is an explicit indication(sign) that tells the process the door is shut. So the process decides that there is no more waiting
The process: Observe either the EOF and say well the job for that door is over, it is time for me to fulfill my function. So it closes on its own. Or it observes a signal sent by the kernel, which in this case the process says: well I don't know if there is supposed to be more inputs coming because the door is not shut (EOF not observed) but it is time for me to fulfill my end of the contract with the kernel.
The kernel: Just enforce termination. You observed your EOF , fulfilled your function now you just got to fulfill your contract and me mine, so I will enforce termination. Or well, you didn't observe your EOF however, I sent you a signal that says you must stop right now, so fulfill your contract and stop even if you did not honor your function, not by choice but it is in our agreement...
To explain the difference between waiting, finishing and killing:
Waiting is an unresolved dependency, in this case stdin... waiting for input...
Finishing is the observation of the EOF and
Killing is the receipt of a signal by the kernel…
Waiting = nothing has been decided
Finishing = the process decided
Killing = the kernel decided
P.S: This reflects my current understanding. If I missed nuance I would appreciate correction. The goal is to get an accurate mental model so it stays in mind and not to be perfect. If there is any questions please don't hesitate to ask.
Top comments (0)