How to terminate sub-thread processes

Hi Li Pang

When you create the thread, set IsBackground = True before you start it
running. That way it will be terminated when the owning thread terminates.

HTH

Charles
Li Pang wrote:

Hi,

I make an app which can run some sub processes through multiple
threads. I'd like to know how to terminate all sub-threads when the
main thread is closed.

thanks in advance

* "=?Utf-8?B?TGkgUGFuZw==?=" <an*******@discussions.microsoft.com> scripsit:

I make an app which can run some sub processes through multiple
threads. I'd like to know how to terminate all sub-threads when the main
thread is closed.

What are the sub threads doing? You can set a Boolean variable that
tells the threads to exit.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

thanks

Hi Charles,

Delights a lot of questions about this I think, thanks from me too.

When you create the thread, set IsBackground = True before you start it
running. That way it will be terminated when the owning thread terminates.

Charles

On Wed, 26 May 2004 11:12:19 +0100, Charles Law wrote:

Hi Li Pang

When you create the thread, set IsBackground = True before you start it
running. That way it will be terminated when the owning thread terminates.

HTH

Charles

Charles,

I'm not so sure this is a good idea... I have to check, but I believe if
you do this then the threads are forcibly terminated - which means that
they are not given an opertunity to run any clean up code. Personally, I
would set a flag to signal the threads to terminate, and then wait for the
children to die before exiting.

--
Tom Shelton [MVP]

Hi Tom,

:-(

However I think you are right when I read this.

So I have nothng to change

:-)

Cor

I'm not so sure this is a good idea... I have to check, but I believe if
you do this then the threads are forcibly terminated - which means that
they are not given an opertunity to run any clean up code. Personally, I
would set a flag to signal the threads to terminate, and then wait for the
children to die before exiting.

Hi Tom

Yes, I should have been more specific. This isn't a good replacement for
terminating a thread in an orderly manner. That said, I have found recently
that using a flag to indicate that the thread does not always work. My
example is where I set my flag to false (to terminate the thread) and then
use thread Join to wait for it to terminate. It never does. If I allow the
application to run on, or use a DoEvents (ugh!), then the thread terminates.
I now use the thread Abort method and trap the exception raised in the
thread. It's not pretty, but it works, and permits some sort of graceful
exit.

Charles
[Incidently, I currently have a problem based on the non-terminating issue
above, that involves SyncLock. There are three threads, including the main
UI thread, all trying to send and receive commands down a serial port. All
commands go out through a single function, making it easier to protect.
However, while the two background threads are hammering away at sending and
receiving commands, if I try to send a command from the UI the UI thread
freezes trying to get a lock on my command queue. Once it does that I can't
find out what the other threads are doing in the debugger, as any
breakpoints I set in the body of the threads are never hit. I'm not sure I
have given you enough to go on, but any suggestions about debugging
multi-threaded apps greatly received.]
Tom Shelton wrote:

On Wed, 26 May 2004 11:12:19 +0100, Charles Law wrote:

Hi Li Pang

When you create the thread, set IsBackground = True before you start
it running. That way it will be terminated when the owning thread
terminates.

HTH

Charles

Charles,

I'm not so sure this is a good idea... I have to check, but I
believe if you do this then the threads are forcibly terminated -
which means that they are not given an opertunity to run any clean up
code. Personally, I would set a flag to signal the threads to
terminate, and then wait for the children to die before exiting.

Tom,
The background thread will have Thread.Abort called, which causes an
Exception to be raised on that thread.

http://msdn.microsoft.com/library/de...roundTopic.asp

http://msdn.microsoft.com/library/de...AbortTopic.asp

If the background thread does its cleanup in Try/Finally blocks (which I
sincerely hope it does) it will clean up nicely.

However! I agree, most of the time I would set a signal to have the worker
threads clean up.

Hope this helps
Jay

"Tom Shelton" <to*@YOUKNOWTHEDRILLmtogden.com> wrote in message
news:m3******************************@40tude.net.. .

On Wed, 26 May 2004 11:12:19 +0100, Charles Law wrote:

Hi Li Pang

When you create the thread, set IsBackground = True before you start it
running. That way it will be terminated when the owning thread terminates.
HTH

Charles

Charles,

I'm not so sure this is a good idea... I have to check, but I believe if
you do this then the threads are forcibly terminated - which means that
they are not given an opertunity to run any clean up code. Personally, I
would set a flag to signal the threads to terminate, and then wait for the
children to die before exiting.

--
Tom Shelton [MVP]

In article <OQ**************@tk2msftngp13.phx.gbl>, Jay B. Harlow [MVP - Outlook] wrote:

Tom,
The background thread will have Thread.Abort called, which causes an
Exception to be raised on that thread.

http://msdn.microsoft.com/library/de...roundTopic.asp

http://msdn.microsoft.com/library/de...AbortTopic.asp

Good to know that the Abort is called - except that in this situation,
I'm not necessarily sure that cleanup will occur. The reason I say that
is that Thread.Abort does not necessarily throw the ThreadAbort
exception immediately... It really depends on the state of the thread
when the abort is called. The main exception being unmanaged code, the
exception will not be thrown until the code re-enters managed code - and
if that is a blocking call, such as those called by the socket classes
:), that could be for quite some time. I'm assuming that the system,
will kill forcibly any threads that do not exit in a timely fashion. I
could be wrong, but it would be interesting to know the answer here.
I've always avoided background threads, just on the principle that I
should make sure that I'm doing what needs to be done :)
--
Tom Shelton [MVP]