When you “kill” a process, on any operating system at all, you are unconditionally forcing it into its exit-path. Your request may be refused: you might not be authorized to kill the process. In any case, the process might have to do an arbitrary number of things in order to finish dying, and it might be delayed for any number of reasons. Some of those reasons might involve resources that you directly or indirectly hold. The process, if it interacts at all with the user interface, will need to change that interface and that can involve grabbing and releasing all kinds of shared locks within the window system. Figurative and literal deadlocks can occur very easily.

If you kill the process, don’t expect to be able to collect any sort of completion-status from it. If you need to wait until after the process has died, set up some kind of timed-wait loop to poll the process-id until the OS says the process doesn’t exist. But, be sure that the loop will end after a finite amount of time. (When you get confirmation that the PID is gone, wait one more time... just in case.) I make these suggestions, not because there are not other ways to do it (operating system dependent ...), but because this strategy keeps the assassin and his prey at arms length from each other, and not dependent for correct operation upon any uncertainties of the outcome. There are many timing potholes on this road.

Also: if you want a process to die, and that process belongs to you, design the process in such a way that it will accept some kind of a signal from you that it should please at once terminate itself. The process should in a good and graceful manner put its affairs in order and, immediately prior to jumping on its own steam into the Great Beyond, transmit a final farewell back to you. Consider also, in that case, whether it is possible and perhaps better for the signal to mean, “immediately quit what you are doing, signal back that you have done so, and then wait ... still very much alive ... for your next instructions.” Even better, let the program set its own timer or what-have-you and to discover for itself, with no external prompting, that it cannot complete the unit of work that it set out to do. Pointing a loaded pistol at a process’s head and pulling the trigger quite without warning, while it may be “effective,” is hardly elegant, and therefore frequently troublesome. If possible, FABWTDI = Find A Better Way To Do It.