Hello,

coming from win32 API I recall an ExitThread() call to gently terminate a
thread from inside the same thread .... but now all I can see is an Abort
call which seems to me a wrapper on the TerminateThread() Win32 API which is
a brutal way to end a thread. Is there any other more gentle way to close a
thread???

Bob Rock

Bob,

You ^could^ call the ExitThread API to exit the thread. However, the
managed concept of a Thread and the actual implementation may not always be
in synch (also, if this thread is from the thread pool, then the results are
unpredictable as well). It is possible that in the future that fibers will
be used to support the managed concept of a thread, for example.

If anything, I would use return values from a method or some other
indicator to exit a thread, not using ExitThread. It just seems like a bad
implementation to "bash" the thread like that.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (E-Mail Removed)



"Bob Rock" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hello,
>
> coming from win32 API I recall an ExitThread() call to gently terminate a
> thread from inside the same thread .... but now all I can see is an Abort
> call which seems to me a wrapper on the TerminateThread() Win32 API which
is
> a brutal way to end a thread. Is there any other more gentle way to close
a
> thread???
>
> Bob Rock
>
>
>

Bob Rock wrote:

> coming from win32 API I recall an ExitThread() call to gently
> terminate a thread from inside the same thread ....

You never should call ExitThread directly, because this normaly leads to
memory leaks (at least from the CRT).

> but now all I can
> see is an Abort call which seems to me a wrapper on the
> TerminateThread() Win32 API which is a brutal way to end a thread. Is
> there any other more gentle way to close a thread???

return !?

--
Greetings
Jochen

Do you need a memory-leak finder ?
http://www.codeproject.com/tools/leakfinder.asp

Do you need daily reports from your server ?
http://sourceforge.net/projects/srvreport/

Say for instance I have a thread that I fire off that's running some loop of
code that's monitoring status or something. I know I could define a
variable in a shared address space, and have that loop until the variable
goes false or something, which would then have the thread exit. Is there a
way though without using this method to cause a thread to shut down without
calling Abort() ?


Ryan Gregg


"Jochen Kalmbach" <nospam-(E-Mail Removed)> wrote in message
news:Xns94E29F71E8246JochenKalmbachholzm@127.0.0.1...
> Bob Rock wrote:
>
> > coming from win32 API I recall an ExitThread() call to gently
> > terminate a thread from inside the same thread ....
>
> You never should call ExitThread directly, because this normaly leads to
> memory leaks (at least from the CRT).
>
> > but now all I can
> > see is an Abort call which seems to me a wrapper on the
> > TerminateThread() Win32 API which is a brutal way to end a thread. Is
> > there any other more gentle way to close a thread???
>
> return !?
>
> --
> Greetings
> Jochen
>
> Do you need a memory-leak finder ?
> http://www.codeproject.com/tools/leakfinder.asp
>
> Do you need daily reports from your server ?
> http://sourceforge.net/projects/srvreport/

Hi,

"Ryan Gregg" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> Say for instance I have a thread that I fire off that's running some loop
of
> code that's monitoring status or something. I know I could define a
> variable in a shared address space, and have that loop until the variable
> goes false or something, which would then have the thread exit. Is there
a
> way though without using this method to cause a thread to shut down
without
> calling Abort() ?

You could throw an exception that is only caught in the main method of the
your thread, then just return.

Or, if you wait on WaitHandle-s, you join with other threads or you sleep a
lot (Thread.Sleep), you could call Thread.Interrupt. The next wait, join or
sleep on the thread will then throw a ThreadInterruptedException. Beware of
general exception handlers that could catch this exception and ignore it.

The nice thing about Thread.Abort is that it throws a
ThreadAbortedException, which is a special kind of exception. It will be
rethrown when caught until the thread exits, or until you call
Thread.ResetAbort.

Cheers,
---
Tom Tempelaere.

I would check a bool or enum (running, stopped, paused, etc) at the top of
the thread loop and exit if the bool or enum is stopped. This var needed to
be synced if multiple threads get/set it (i.e. reader is your worker, writer
is your caller.) This is the first best way for the standard path.
Sometimes this may not be checked as you could be waiting for event or
blocking on i/o, etc. One reason to use timeouts on wait operations. In
your Stop method, set the bool and wait some period of time to allow thread
to stop, calling join(timeout) with some reasonable timeout. If it does not
join, then your next step could be thread.abort() and another join, maybe in
a loop to do 1 or more times. Your worker thread should catch the exception
and allow you to run finally, etc. and reset the thread.abort reset deal and
exit as cleanly as it can in code.

--
William Stacey, MVP

"Bob Rock" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hello,
>
> coming from win32 API I recall an ExitThread() call to gently terminate a
> thread from inside the same thread .... but now all I can see is an Abort
> call which seems to me a wrapper on the TerminateThread() Win32 API which
is
> a brutal way to end a thread. Is there any other more gentle way to close
a
> thread???
>
> Bob Rock
>
>
>

> You could throw an exception that is only caught in the main method of the
> your thread, then just return.
>

Probably a stupid question, but, how do you throw and exception from a
thread (the main thread) that needs to be caught by another thread (the
worker thread)????

Bob Rock

"Bob Rock" <(E-Mail Removed)> wrote in message
news:enT2%(E-Mail Removed)...
> > You could throw an exception that is only caught in the main method of
the
> > your thread, then just return.
> >
>
> Probably a stupid question, but, how do you throw and exception from a
> thread (the main thread) that needs to be caught by another thread (the
> worker thread)????
>

could Thread.Interrupt() do that?

from a pure visual c,native programmer,
maybe this can help,
I know dotnet has more to offer, but in this case I think it's same thing...

at design time, if the thread to end does some sort of loop/polling, in that
loop check for a global flag that when changes status, makes it exit,
you'd change status from another thread.
you can use enevts too if you will.
your thread-to-end may be simple doing a WaitForSingleObject/MultipleObject
on a given global event handle.

there isn't a nice way to 'kill' 'end' 'terminate' a thread.
unfortunately, if you dont design the software to end gracefully a thread.
the TerminateThread is the only solution but you'll have 1MB stack lost for
sure, and probably some leaks and curruption.

"Bob Rock" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hello,
>
> coming from win32 API I recall an ExitThread() call to gently terminate a
> thread from inside the same thread .... but now all I can see is an Abort
> call which seems to me a wrapper on the TerminateThread() Win32 API which
is
> a brutal way to end a thread. Is there any other more gentle way to close
a
> thread???
>
> Bob Rock
>
>
>

Hi,

"spammy" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> "Bob Rock" <(E-Mail Removed)> wrote in message
> news:enT2%(E-Mail Removed)...
> > > You could throw an exception that is only caught in the main method of
> the
> > > your thread, then just return.
> > >
> >
> > Probably a stupid question, but, how do you throw and exception from a
> > thread (the main thread) that needs to be caught by another thread (the
> > worker thread)????
> >
>
> could Thread.Interrupt() do that?

Yes.

Interrupt called on a certain Thread object, will throw an exception on the
actual thread that the object represents, on the next wait, sleep or join
operation performed on that thread, or if the thread is already waiting,
joining or sleeping (WaitHandle::Waitxxx, Thread::Sleep, Thread::Join). The
exception is of type ThreadInterruptedException.

Abort called on a certain Thread object, will throw an exception on the
actual thread that the object represents, period. The exception is of type
ThreadAbortedException. There is one exception (no pun). The framework
cannot throw the exception if the thread is executing interop code (i.c. it
can only be thrown from managed code).

It does not matter from which thread or on what Thread object you call Abort
or Interrupt, so you can call these methods on the current thread being
executed. Calling Thread.Abort from the current thread will surely throw a
ThreadAbortedException. You can easily verify, just execute the following on
a thread:

Thread.CurrentThread.Abort();

Add a catch handler for the exception, you will see.

Cheers,
---
Tom Tempelaere