managed threading / native exception handling question

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

osudude - 12 Jun 2007 04:32 GMT

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

Reply to this Message

Oleg Starodumov - 12 Jun 2007 16:37 GMT

> What happens in the following scenario?
>
[quoted text clipped - 5 lines]
> 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.

Signature

Oleg
[VC++ MVP http://www.debuginfo.com/]

Reply to this Message

adebaene@club-internet.fr - 13 Jun 2007 10:40 GMT

> What happens in the following scenario?
>
[quoted text clipped - 8 lines]
> 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

Reply to this Message

Ben Voigt [C++ MVP] - 13 Jun 2007 18:14 GMT

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

> Arnaud
> MVP - VC

Reply to this Message

managed threading / native exception handling question

Free Magazines