Question

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?

Answer 1

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