Developer Forum

Some basic questions regarding Thread.Abort() and remoting.

If Thread.Abort() is called on a client thread while that thread is calling
a remote object, it seems that the ThreadAbortException is not thrown until
the remote method call returns. It seems that the Thread.Abort() signal does
not propagate across the remoting boundary. Can someone confirm this
behavior? Is there any additional available documentation about this issue?

Indeed it seems similar to the way Thread.Abort() works across the boundary
between managed and unmanaged code. If Thread.Abort() is called on a thread
that is waiting on a call to unmanaged code, like a call to a COM component,
again the ThreadAbortException is not thrown until the method returns from
the call to unmanaged code.

We are aware of other thread limitations as per the article:
How To Stop a Thread in .NET (and Why Thread.Abort is Evil)
http://www.yqcomputer.com/

Just wondering if there was any additional information about Thread.Abort()
limitations with regards to remoting.

Thanks.

Thread.Abort does have some special properties. It doesn't just kill your
thread, but instead the CLR inserts code into your currently executing
method to raise a ThreadAbortException immediately after the current
statement. This allows any exception handlers you have registered to do
their clean-up. If the exception handler swallows the exception, the CLR
ensures that the ThreadAbortException is thrown again as soon as you exit
the exception handler. In this way the exception is guaranteed to progress
up your call stack, invoking each exception handler and thus ensuring that
you clean up gracefully. Once the exception reaches a point where no more
exception handlers exist, the thread is terminated. You can call
Thread.ResetAbort to halt this process.

Now I am not sure about your existing situation, since I haven't tried to
use Thread.Abort with Remoting, but it seems to me that it wouldn't be able
to abort the remote thread, merely the one int the current AppDomain, and
that only once the thread returns back to the caller. Similarly, Interop
calls can be thought of as occurring on a thread outside the CLR's control.
It may actually be the same physical thread, but the CLR hands
responsibility for the thread over to the OS when performing Interop, and is
returned control when the Interop call returns.

In article < XXXX@XXXXX.COM >,
XXXX@XXXXX.COM says...

As per docs:
<cite>
If, while executing unmanaged code, a thread ignores a
ThreadAbortException, the system re-throws the ThreadAbortException when
the thread begins executing managed code.
</cite>

When a remoting call is in place, the thread is blocked in unmanaged
code (sockets), waiting for a response. So the exception will be thrown
after a response is received, or the call times out, and the execution
is returned in the managed code.

When I need to interrupt a long duration remoting call, usually I send a
signal to the server to not continue to execute the code, but to return.

Cheers
Sunny