ThreadAbortException

[Bonj]

Say if i have a function,

void FuncStart()
{
try
{
FuncDoActions();
//<nextlineofcode>
}
catch(ThreadAbortException)
{
Thread.ResetAbort();
}
}

If I start a thread by calling
System.Threading.Thread mythread = new
System.Threading.Thread(new System.Threading.ThreadStart
(FuncStart))

and then I call mythread.Abort(),
would the thread abort abruptly IN THE MIDDLE of
FuncDoActions, or would it complete to the end of
FuncDoActions() but just not do <nextlineofcode>?

If it makes any difference, the code to start the thread
will be in a different method of the same (thread-safe)
class that FuncStart is in.

 

[Nicholas Paldino [.NET/C# MVP]]

Bonj,

It is going to abort in FuncDoActions. It will not wait until
FuncDoActions is complete to stop execution on that thread. The only
exception to this is when you are making a call to unmanaged code. In this
case, the call to unmanaged code will complete before the thread terminates.

Hope this helps.

 

[Alvin Bruney]

No, that's not strictly correct.

It all depends on what the thread is doing. It can *choose not to respond to
the abort in the middle of the function if it were in a tight loop for
example. In that case the thread would only honor the abort request after
the function is popped off the call stack. To be technically correct, it
depends on where the thread is and what it is doing.

--
Regards,
Alvin Bruney
Got tidbits? Get it here...
http://tinyurl.com/2bz4t

Bonj,

It is going to abort in FuncDoActions. It will not wait until
FuncDoActions is complete to stop execution on that thread. The only
exception to this is when you are making a call to unmanaged code. In this
case, the call to unmanaged code will complete before the thread terminates.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Say if i have a function,

void FuncStart()
{
try
{
FuncDoActions();
//<nextlineofcode>
}
catch(ThreadAbortException)
{
Thread.ResetAbort();
}
}

If I start a thread by calling
System.Threading.Thread mythread = new
System.Threading.Thread(new System.Threading.ThreadStart
(FuncStart))

and then I call mythread.Abort(),
would the thread abort abruptly IN THE MIDDLE of
FuncDoActions, or would it complete to the end of
FuncDoActions() but just not do <nextlineofcode>?

If it makes any difference, the code to start the thread
will be in a different method of the same (thread-safe)
class that FuncStart is in.

 

[Dave]

What are you basing this opinion on?

 

[Bonj]

Is it possible I can define a block of code that it will
wait till it gets to the end of before honouring an abort
request?

In that case the thread would only honor the abort request after
the function is popped off the call stack.

This is what I want to happen, but it seems like if even
the experts are unsure as to what the exact behaviour is,
it's probably not something I want to be relying on! I
think I'll use a variable to signal it instead.

To be technically correct, it
depends on where the thread is and what it is doing.

Depends on....?

--
Regards,
Alvin Bruney
Got tidbits? Get it here...
http://tinyurl.com/2bz4t
"Nicholas Paldino [.NET/C# MVP]"

message news:[email protected]...

Bonj,

It is going to abort in FuncDoActions. It will not wait until
FuncDoActions is complete to stop execution on that thread. The only
exception to this is when you are making a call to

unmanaged code. In
this

case, the call to unmanaged code will complete before

the thread
terminates.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Say if i have a function,

void FuncStart()
{
try
{
FuncDoActions();
//<nextlineofcode>
}
catch(ThreadAbortException)
{
Thread.ResetAbort();
}
}

If I start a thread by calling
System.Threading.Thread mythread = new
System.Threading.Thread(new System.Threading.ThreadStart
(FuncStart))

and then I call mythread.Abort(),
would the thread abort abruptly IN THE MIDDLE of
FuncDoActions, or would it complete to the end of
FuncDoActions() but just not do <nextlineofcode>?

If it makes any difference, the code to start the thread
will be in a different method of the same (thread- safe)
class that FuncStart is in.

.

 

[Bonj]

Thanks

What do you define as unmanaged code? Code that uses any
managed object? Or code in which every line involves a
managed object? Will it just get to the next line that
doesn't involve a managed object? Or what?

-----Original Message-----
Bonj,

It is going to abort in FuncDoActions. It will not wait until
FuncDoActions is complete to stop execution on that thread. The only
exception to this is when you are making a call to unmanaged code. In this
case, the call to unmanaged code will complete before the thread terminates.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Say if i have a function,

void FuncStart()
{
try
{
FuncDoActions();
//<nextlineofcode>
}
catch(ThreadAbortException)
{
Thread.ResetAbort();
}
}

If I start a thread by calling
System.Threading.Thread mythread = new
System.Threading.Thread(new System.Threading.ThreadStart
(FuncStart))

and then I call mythread.Abort(),
would the thread abort abruptly IN THE MIDDLE of
FuncDoActions, or would it complete to the end of
FuncDoActions() but just not do <nextlineofcode>?

If it makes any difference, the code to start the thread
will be in a different method of the same (thread-safe)
class that FuncStart is in.

.

 

[Dave]

Is it possible I can define a block of code that it will
wait till it gets to the end of before honouring an abort
request?

No. That is one of the current limitations of .net; it is supposed to be
changed in a future release so that finally blocks cannot be interrupted by
a thread abort. Currently any line of code can be interrupted.

This is what I want to happen, but it seems like if even
the experts are unsure as to what the exact behaviour is,
it's probably not something I want to be relying on! I
think I'll use a variable to signal it instead.

If you really want to be safe then you should never use Abort unless it is a
thread aborting itself - in this case the abort is synchronous so as long as
it does not throw it in a sensitive area you should not have a problem. From
another thread you can set a variable, signal an event, etc. to act as a
signal to the other thread that it should terminate itself.

Another potential danger is that if you exit your application without
unwinding all your threads, either by returning from the last foreground
thread or by using one of the Exit APIs (e.g. Environment.Exit), then all
other threads are suspended and never resumed, which means that none, repeat
none, of your finally blocks will be run. Finalizers will run but finally
blocks will not. This means that you cannot rely on the existence of a
finally block to ensure that the code in it will be executed; you must also
make sure that you gracefully terminate all threads that have cleanup code
you want executed before you exit your application.