Re: Kill a process in perl windows and proceed only if it killed the process

[sundialsvc4]

in reply to Kill a process in perl windows and proceed only if it killed the process

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.

[BrowserUk]

When you “kill” a process, on any operating system at all, you are unconditionally forcing it into its exit-path.

No. You are not! You are so wrong here it isn't even funny.

Why do you do this?

Why do you spout such crap, at such length on subjects that you obviously have not the vaguest clue about?

[bulk88]

Sundial is somewhat correct. On all OSes, there are voluntary closes, and forced closes. On unix there are different signals and different kill -* numbers. On Windows there is WM_CLOSE message, or SetConsoleCtrlHandler (which under the hood is a csrss.exe getting a WM_CLOSE or a control C message), these 2 are voluntary. Then there is TerminateProcess which is forced.

TerminateProcess I know is privilage checked (not sure about how windows messages work). Also on NT Kernel, if a process did certain syscalls, (my specific experience is with NtCreateFile/CreateFile), a driver can freeze a thread, and absolutely nothing can terminate that process since NT Kernel runs a kernel mode APC (think unix signal) in each thread to terminate each thread and the process/PID disappears when the last thread is removed from the process, but the thread is stuck in a blocking synchronous IO call in a driver, the kernel can not preempt most kernel mode code (google IRQL) executing in a thread to schedule an APC. Basically, CreateFile is synchronous, the path driver UNC/My Network Places driver which implements "\\1.2.3.4\someshare" paths on NT is crap. This driver is called MUP, which is one of many MS schemes at user mode drivers. MUP connects to Workstation/COmputer Browser services, which does the actual socket IO from user mode. Why? Either MS decided kernel socket interface in the kernel is so difficult to use, or MS's My Network Places/Samba/CIFS implementation still uses DOS/16 bit code that was ported to 32 bits, but still has to be run in user mode. NT 6/Vista introduced a a couple new calls to cancel sync I/O in any thread from any thread, so perhaps this unterminatable process problems doesn't exist anymore in NT 6. When Explorer freezes for many seconds or file open freezes for many seconds when browsing network shares, blame CreateFile and MUP.

[BrowserUk]

The problem is not that there aren't one or two very obscure circumstances on particular OSs where some tiny percentage of what he said might just be inferred to be "somewhat correct". It is that he has no specific knowledge of those specific circumstances; and would not be able to identify them.

Like mind-readers, sooth-sayers and astrologists; if he makes what he says generic enough; and vague enough; and avoids any verifiable technical details or references; then it is possible to interpret it as being "somewhat correct", at some times. But it doesn't mean there is any real knowledge at work.

A thought

Does your knowledge really extend to "all OSs"? Mine doesn't.

For example, on *nix/POSIX the only mechanism I know of, for terminating a running process, is to send it a signal. But signals are maskable, trappable, and ignorable. Are any of them guaranteed to terminate the process? Do you know the answer? I don't. Do you think he does?

How's your knowledge of BSD, Solaris, HP-UX, VMS, TSO, NT4/5/6/7/8, Windows Server 2000/2003/2005/2008/2010/2012 ... Could you make sweeping statements about *all of them*? I couldn't.

And it is very clear that he should not. Please do not encourage him.