Safely Closing A Thread

Question

I'm writing a bit of code that will open a MessageBox on a separate thread to prevent the MessageBox from stopping the program. It is very very important that starting a new thread will not crash the program that I am running, but I don't know enough about threads to make sure this happens.

My question is, after starting the thread, how can I safely dispose of it after the MessageBox closes? I imagine closing/disposing of it is necessary so it's not just floating around after it is created and started.

Please advise, thanks!

var Thread = new Thread
(
    ()=>
    {
        MessageBox.Show("Buy pizza, Pay with snakes");
    }
);
Thread.Start();

Answer 1

You don't need to do anything special.

Thread instances are automatically "cleaned up" (rather they become candidates for garbage collection) when there's no references to them (in your code) and their main method body has terminated. In fact, Thread doesn't implement IDisposable - so speaking of it's "disposal" is incorrect.

In your example, once the lambda method completes (ie the message box is closed), the thread will automatically terminate. You don't need to do anything extra.

Now there's a difference between reclaiming allocated memory and having objects become candidates for disposal/collection. Any objects allocated will remain on the GC heap until the next collection cleans them up ... but you shouldn't have to care about that.

A separate issue you may need to contend with is performing UI operations on a thread other than the main UI thread. While it is possible, you have to be careful not to reference any UI elements that are created on a different thread from the one you create.

Answer 2

A Thread will automatically clean itself up once the code contained within it completes. You don't have to manually dispose of it (and, in fact, it's not IDisposable!).

Answer 3

The thread will close automatically after the scope of the lambda expression is left... in your case you don't need to worry about anything.

In general it's also good practice to set the thread to background, because if your application is closed you might get a message box just hanging out there by itself:

var thread = new Thread(
    ()=>
    {
        MessageBox.Show("Buy pizza, pay with snakes");
    });
thread.IsBackground = true;
thread.Start();

Note: it's preferred that your variables start with a lower letter. For details on naming conventions please see the Microsoft Naming Guidelines.

Answer 4

A few things first...

1. Threads don't "crash" the program unless an unhandled exception is thrown from within it.
2. You don't need to dispose of a thread. Finishing its main routine is enough.
3. If necessary, you can make your program wait for the end of the thread execution using the Join() method on your Thread instance.

And then a suggestion: it seems that you need a modeless MessageBox. AFAIK, the feasible way of doing this is creating a custom form and display it through Show() instead of ShowDialog().

Answer 5

In C#, you shouldn't have to care all that much once the thread goes out of scope. It's a simple answer, but simple is good: let the computer do what it's good at. :-)

Answer 6

You should be aware that if an exception is thrown by your worker thread and is not caught, then your application may abort (as Humberto mentioned in point #1). The example you provided is trivial, and I can't imagine that it would throw an exception, but you may want to consider at least wrapping the worker thread logic in a try/catch.

I would suggest not using a separate thread for this purpose. Create your own form for displaying the message and show it with the Show method. Creating a form like this isn't too difficult; I recommend making use of the Button.DialogResult, Form.AcceptButton, and Form.CancelButton properties. You have more control over the appearance of the form

In terms of reliability, an advantage of keeping your code out of a worker thread is that you can subscribe to the Application.ThreadException event in order to handle any exceptions that were not caught by your application's logic. This allows you to prevent your application from crashing due to an unhandled exception, but be aware that this will affect your entire application.