|
in reply to ***Warning! The above post is wrong in almost every possible way***
in thread Kill a process in perl windows and proceed only if it killed the process
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. |
Re^2: ***Warning! The above post is wrong in almost every possible way***
by BrowserUk (Patriarch) on Jul 21, 2012 at 10:34 UTC
|
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.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
| [reply] |
|
|
"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?"
I certainly can't answer for all OSes, nor even all Unix-like OSes, but on Linux, SIGKILL (signal 9) cannot be trapped. SIGKILL is essentially the untrappable version of SIGINT (which is what Ctrl+C tends to send in the terminal).
Also, SIGSTOP cannot be caught, but SIGSTOP doesn't kill a process, it pauses it. SIGSTOP is the untrappable version of SIGTSTP (which is what Ctrl+Z tends to send in the terminal).
Of course, just because a process cannot trap and handle the signal, doesn't mean that the signal is 100% instant and reliable. Signals can fail to work, or take some time to work for other reasons (e.g. bugs, busy CPU, etc).
Aside: If a process is chewing up your CPU and you need to stop it for a while, kill -s STOP <process_number> is a pretty handy facility. When you're happy for it to start chewing again kill -s CONT <process_number> will restart it. The process is unlikely to even notice you paused it.
perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'
| [reply]
[d/l]
[select] |
|
|
on Linux, SIGKILL (signal 9) cannot be trapped.... just because a process cannot trap and handle the signal, doesn't mean that the signal is 100% instant and reliable.
Indeed. The Uninterruptible sleep state for example.
you need to stop it for a while, kill -s STOP <process_number> is a pretty handy facility.
Similarly, windows has suspend/resume which I frequently use to pause longing running, CPU intensive tasks when I want to do something else for a while, but don;t want to throw away the work already done.
The only downside is that if you are benchmarking the process, the suspend will affect the timing if you use real-time clocks. Recently, I've moved to using clock-cycle counters for important benchmarking for this reason.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
| [reply] |
|
|
