managed threading / native exception handling question

  • Thread starter Thread starter osudude
  • Start date Start date
O

osudude

What happens in the following scenario?

1.Via a DLL interface, a managed thread kicks off a potentially long running
FOR loop operation encapsulated by a native C++ dll. This FOR loop has C++
try/catch logic and allocates memory using calloc.
2. The managed thread is aborted before step 1 can complete.

In a pure managed environment, you would catch ThreadAbortException and
handle it appropriately (log error and do clean up). Is some kind of
similar exception thrown in the C++ dll to indicate thread abortion or is
the thread just killed with no opportunity for exception handling / clean up
logic?

thanks!

ScottM
 
What happens in the following scenario?

1.Via a DLL interface, a managed thread kicks off a potentially long running FOR loop operation encapsulated by a
native C++ dll. This FOR loop has C++ try/catch logic and allocates memory using calloc.
2. The managed thread is aborted before step 1 can complete.

In a pure managed environment, you would catch ThreadAbortException and handle it appropriately (log error and do
clean up). Is some kind of similar exception thrown in the C++ dll to indicate thread abortion or is the thread just
killed with no opportunity for exception handling / clean up logic?

The thread will not be terminated, and there will be no exception until
the long operation has been completed and control has been returned to
managed code. Only after that ThreadAbortException will be thrown
in the target thread.
 
What happens in the following scenario?

1.Via a DLL interface, a managed thread kicks off a potentially long running
FOR loop operation encapsulated by a native C++ dll. This FOR loop has C++
try/catch logic and allocates memory using calloc.
2. The managed thread is aborted before step 1 can complete.

In a pure managed environment, you would catch ThreadAbortException and
handle it appropriately (log error and do clean up). Is some kind of
similar exception thrown in the C++ dll to indicate thread abortion or is
the thread just killed with no opportunity for exception handling / clean up
logic?
From the Thread.Abort documentation :

"If, while executing unmanaged code, a thread ignores a
ThreadAbortException, the system re-throws the ThreadAbortException
when the thread begins executing managed code."

Arnaud
MVP - VC
 
From the Thread.Abort documentation :
"If, while executing unmanaged code, a thread ignores a
ThreadAbortException, the system re-throws the ThreadAbortException
when the thread begins executing managed code."

And I think that is only applicable to a callback into managed code. Trying
to abort from another thread won't cause any ThreadAbortException at all
until the target thread returns to managed code. .NET Framework pulls some
tricks, like rewriting the return address on the stack placed by the call
into unmanaged code (and does this for GC as well), that is part of why
there is overhead for transitions between managed and unmanaged. But it
definitely does not trigger an exception asynchronously, that isn't possible
without writing directly to internal OS data structures (kernel level access
required I believe) and is *very* unsafe.
 
Back
Top