.NET Process.Kill() in a safe way
I'm controlling a creaky old FORTRAN simulator from a VB.NET GUI, using redirected I/O to communicate with the simulator executable. The GUI pops up a "status" window with a progress bar, estimated time, and a "STOP" button (Button_Stop
).
Now, I want the Button_Stop
to terminate the simulator process immediately. The obvious way to do this is to call Kill()
on the Child
Process object. This gives an exception if it's done after the process has exited, but I can test whether the process is exited before trying to kill it, right?
OK, so I do the following when the button is clicked:
If Not Child.HasExited Then
Child.Kill()
Button_Stop.Enabled = False
End If
However, what if the process happens to exit between the test and the call to Kill()
? In that case, I get an exception.
The next thing to occur to me was that I can do Button_Stop.Enabled = False
in the Process.Exited
event handler, and thus prevent the Child.Kill()
call in the Button_Stop.Clicked
handler. But since the Process.Exited
handler is called on a different thread, that still leaves the following possible interleaving:
- Child process exits.
Process.Exited
fires, callsInvoke
to schedule theButton_Stop.Enabled = False
- User clicks on
Button_Stop
, triggeringChild.Kill()
Button_Stop.Enabled = False
actuall开发者_开发百科y happens.
An exception would then be thrown on step 3.
How do I kill the process without any race conditions? Am I thinking about this entirely wrong?
Simply catch the exception and disable the button in finally
:
Try
Child.Kill()
Catch ex As Exception
MsgBox(ex.ToString())
Finally
Button_Stop.Enabled = False
End Try
Instead of catching all types of exceptions it would of course be better to only catch InvalidOperationException
and Win32Exception
as these are thrown if the process is terminating or already exited.
You probably think it is a "bad thing" if exceptions occur in a program and that you should design your program to avoid exceptions at all. However, there are different types of exceptions and exception handling, some being bad design decisions, and others - like this one - being mandatory, as the reason for the exception (i.e. the termination of another process) is out of your control.
If you want to read further I recommend you Eric Lipperts posts on different kinds of exceptions:
Fabulous Adventures In Coding: Vexing exceptions
You can P/Invoke into TerminateProcess
which won't throw if the process has already exited:
Sub Main()
Dim p = Process.Start("C:\Windows\system32\notepad.exe")
Thread.Sleep(1000)
TerminateProcess(p.Handle, 0)
TerminateProcess(p.Handle, 0) ''# This call won't throw, it will just fail silently.
End Sub
<DllImport("kernel32.dll", SetLastError:=True)>
Private Function TerminateProcess(ByVal hProcess As IntPtr, ByVal uExitCode As UInteger) As <MarshalAs(UnmanagedType.Bool)> Boolean
End Function
精彩评论