2

For a time/date driven threading application I'm using threads that are created (new Thread() and the threads are all put into a list) in which a method is called that runs for an undefined time (can be 1 second or even a full day). In this method a new (sub)thread can be created (also with new Thread()).

Now, when the threading part of the application is ended (manually or because the program ends) I'm going through my list of threads that I had created and end those manually.

Now as far as I understand it the end of the thread that created the subthread (thus the thread that housed the method where the second thread was created) does not mean the end for the subthread. So my question is: Is there any good way to manage it that a thread kill does cascade to its children (or am I misunderstanding how the threads are working there?).

Edit: As it was asked: All threads mentioned here are background threads (thus a background process creates a child-background process that shall end when the parent ends).

Kristof U.
  • 1,263
  • 10
  • 17
Thomas
  • 2,886
  • 3
  • 34
  • 78
  • Are these background threads or foreground threads? (Is it safe to assume the former?) – Sayse Jul 15 '14 at 06:55
  • All of these threads are background threads. (the foreground thread is not mentioned in the post, but is a winforms application where the user does something while the time/date driven threading is just background operations for making the users live easier) – Thomas Jul 15 '14 at 07:01
  • If they are background threads you don't need to worry. CLR will stop all the background threads when process exits. – Sriram Sakthivel Jul 15 '14 at 07:04
  • as far as I understood only when all of the foreground processes stop. but in this case I have a background process that starts another background process which I need to stop as soon as the first background process stops or (like I meantioned in case I misunderstand how threads are working there in C#) is that still automatically the case? – Thomas Jul 15 '14 at 07:06
  • The quote I was looking for basically says what Sriram already mentions... ["Background threads are identical to foreground threads with one exception: a background thread does not keep the managed execution environment running."](http://msdn.microsoft.com/en-gb/library/h339syd0.aspx) – Sayse Jul 15 '14 at 07:09
  • in this case though the foreground process is still running while I want to kill the background processes (it can be that some of the backgorund processes hang up [file.open can do that here due to a few system architecture things that are quite unusal] which I have a cleanup thread taking care of things like that. – Thomas Jul 15 '14 at 07:12

1 Answers1

6

You should stop your threads in a controlled manner, not letting them be killed by the os (assuming they are background threads) or calling Thread.Abort(), if thats what is meant with "thread killing".

Create a CancellationToken with CancellationTokenSource and provide each SubThread with this token. The methods / loops inside the threads should check token.IsCancellationRequested(). You then only need to call TokenSource.Cancel once (in your main thread).

See How to use the CancellationToken property?

Community
  • 1
  • 1
Udontknow
  • 1,472
  • 12
  • 32
  • ok so there is no automatical method that the process can take its childprocess down with it. only manual ones via cancellationtoken (in my exact case I can't trust those as I have threads that can hangup time and again) or via calling thread.abort (or OS takes care if all foreground processes are shut down). – Thomas Jul 15 '14 at 07:24
  • 1
    @ThomasE.: if some background operation may hang up, than you should consider to run them in separate **processes**, instead of threads. There's no way to guarantee, that you can kill particular managed thread (e.g., when thread is executing unmanaged code). – Dennis Jul 15 '14 at 07:48
  • Interesting point there @Dennis so it can be that thread.Abort fails for unmanaged code that hanged up? (also as edit to above: It can be that some processes take QUITE long until I could reach a cancellation token as the underlying method that is called takes long to process the information and can't be splitted up more to allow faster reaching of cancellation tokens that is in adition to the possible hangups). – Thomas Jul 15 '14 at 07:53
  • Tnx there that clarified it. – Thomas Jul 15 '14 at 09:10