views:

299

answers:

2

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:

  1. Child process exits.
  2. Process.Exited fires, calls Invoke to schedule the Button_Stop.Enabled = False
  3. User clicks on Button_Stop, triggering Child.Kill()
  4. Button_Stop.Enabled = False actually 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?

+2  A: 

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

0xA3
That will work, but it seems awkward because it simply drops an exception on the floor. Isn't it good practice to construct programs that will never encounter exceptions in normal operation?
Orborde
@Orbode: It may seem awkward to you, but such exogenous exceptions should be handled using a try-catch block. Further reading: http://blogs.msdn.com/ericlippert/archive/2008/09/10/vexing-exceptions.aspx
0xA3
@Orborde that's only the recommended thing to do if you're catching .NET exceptions. In this case you're catching non-managed Exceptions so it's ok to catch everything
Chris S
+1  A: 

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
Chris Schmich
In fact, `Process.Kill()` simply calls `TerminateProcess` and throws if the return value is zero or the process handle no longer is valid. However, there is no need to call `TerminateProcess` twice as in your sample.
0xA3
Right, just demonstrating that it won't throw :) Edited for clarity.
Chris Schmich