managed threading / native exception handling question

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
 
O

Oleg Starodumov

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.
 
A

adebaene

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
 
B

Ben Voigt [C++ MVP]

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top