Thread.Abort

[C# Learner]

Is it *ever* safe to call Thread.Abort? In which cases it is so?

 

[Richard Blewett [DevelopMentor]]

Currently, in version 1.0 and 1.1 it is safe in two situations:

1) You may Abort the current thread (Thread.CurrentThread.Abort(); )
2) If you are taking down an AppDomain you can Abort all the threads running within that AppDomain

Thats it.

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

Is it *ever* safe to call Thread.Abort? In which cases it is so?

 

[David Levine]

Currently, in version 1.0 and 1.1 it is safe in two situations:

1) You may Abort the current thread (Thread.CurrentThread.Abort(); )
2) If you are taking down an AppDomain you can Abort all the threads
running within that AppDomain

Minor point - when an appdomain is unloaded a Thread.Abort is injected into
all threads by the runtime - the user's code does not need to do this. It is
also an undeniable abort, in that even if the app code resets the abort the
runtime will ignore and continue to propagate the exception up the call
stack.

 

[David Browne]

Currently, in version 1.0 and 1.1 it is safe in two situations:

1) You may Abort the current thread (Thread.CurrentThread.Abort(); )
2) If you are taking down an AppDomain you can Abort all the threads
running within that AppDomain

Thats it.

Look at:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/terminatethread.asp

I would add to your examples that it is safe to terminate a background
thread, when you know it's in a wait state.

EG
This thread

void threadProc()
{
while (!shutdown)
{
WaitForSingleObject(flarg,INFINITE);
... some short-running code
}

}

Can be safely aborted by this:

shutdown = true;
if (!backgroundThread.join(1000))
{
backgroundThread.abort();
}

Meaning you can safely abort background threads which you know to be in a
long wait, and which are coded to exit on an exception.

Now, if possible you should code a signal to abort the wait state, but
that's really neither here nor there. Sometimes it's appropriate to have a
long-running wait on some object, and if you have confidence that a
background thread is in that state, you can abort it if you need to.

David

 

[Richard Blewett [DevelopMentor]]

Surely in that situation Interrupt is better anyway - it will do the msa ejob and will be safe even if you happen to be wrong about it being in a lng wait (maybe its just woken up)

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog


I would add to your examples that it is safe to terminate a background
thread, when you know it's in a wait state.

EG
This thread

void threadProc()
{
while (!shutdown)
{
WaitForSingleObject(flarg,INFINITE);
... some short-running code
}

}

Can be safely aborted by this:

shutdown = true;
if (!backgroundThread.join(1000))
{
backgroundThread.abort();
}

Meaning you can safely abort background threads which you know to be in a
long wait, and which are coded to exit on an exception.

Now, if possible you should code a signal to abort the wait state, but
that's really neither here nor there. Sometimes it's appropriate to have a
long-running wait on some object, and if you have confidence that a
background thread is in that state, you can abort it if you need to.

David





---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.775 / Virus Database: 522 - Release Date: 08/10/2004



[microsoft.public.dotnet.framework]

 

[C# Learner]

Currently, in version 1.0 and 1.1 it is safe in two situations:

1) You may Abort the current thread (Thread.CurrentThread.Abort(); )

Ah, I forgot about this one.

2) If you are taking down an AppDomain you can Abort all the threads running within that AppDomain

Thanks.