Can I safely rely on IsBackground in Threads when the application terminates?

Question

I'm running some background threads in the GUI. Currently I'm implementing a personal Thread cancellation code but there is IsBackground property in threads and according MSDN they'll cancel themselves.

I know that it's going to Thread.Abort() which is nasty but there is nothing going in this background threads that I need to keep a proper state or requires proper clean-up.

I'm trying to avoid any crashes if the user just closes down the application in the middle of a background thread. Since multi-threading scenarios are quite hard to test I'd like to get your opinion on the subject.

Basically, instead of rolling my own code shall I just set IsBackground = True and forget about the rest?

Gowrie

Answer 1

Thread.Abort throws an exception, so if your code is already correctly written to use finally/using, it should fail gracefully and release all resources.

edit

I should probably give a little more detail. First, the exception is of type ThreadAbortException. The interesting thing is that, even if you catch it and do nothing, it doesn't go away. In other words, as soon as it leaves your catch block, it continues to be thrown. This is so that the (typically bad) practice of catching Exception and swallowing it doesn't stop the thread from getting aborted. If you do actually want to stop the abort, you need to catch the exception, then call Thread.ResetAbort.

Hemimorphic

Answer 2

The MSDN page on the IsBackground property states:

A thread is either a background thread or a foreground thread. Background threads are identical to foreground threads, except that background threads do not prevent a process from terminating. Once all foreground threads belonging to a process have terminated, the common language runtime ends the process. Any remaining background threads are stopped and do not complete.

So it would imply to me that you'd have to make your thread quite defensive to ensure that it didn't leave any connections open, databases half written etc. Anything critical would need to be in a foreground thread that would prevent the application closing until it completed.

Structuralism

Answer 3

Jonathan Greensted's post has a good summary about IsBackground :

The IsBackground property allows you to tell the runtime if the thread is a foreground (UI) thread or a background thread. By default all threads are created as foreground threads unless you change this property.

So why do we care?

Well, the .NET runtime does something special when the last foreground thread terminates - it aborts all the background threads and terminates the application. (We know Thread.Abort is bad however if the application is being shutdown anyway that badness has a very limited duration.)

To put it another way, is the work being done in the background thread ok to be stopped at any point when the application closes?

If not then it should probably be a foreground thread - so a thread working with file handles or opening database connections should ideally be foreground where an application quit will wait for this thread to finish before quiting.

Penrod

Answer 4

I think this depends on the resource. For example, socket is closed safely when process ends. For some resource you'd better release it before quit the thread.

Nan