Re: Thread.Abort() vs. Unmanaged Code
From: David Levine (noSpamdlevineNNTP2_at_wi.rr.com)
Date: 09/21/04
- Next message: Jonathan Pierce: "Re: Decompiler.NET reverse engineers your CLS compliant code"
- Previous message: Flare: "(IOC and AOP (Aspect oriented programming)"
- In reply to: Christian Kesselheim via .NET 247: "Thread.Abort() vs. Unmanaged Code"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 21 Sep 2004 18:40:22 -0500
If you really need to kill the control and all its threads then your idea is
a good one. That allows you to use the isolation provided by the win32 OS
itself to prevent corruption of the .net process your own code runs in. If
you want to kill a thread in an unclean manner (e.g. using Win32's
TerminateThread from within .net) there are all kinds of problems that you
will run into if the process itself keeps running, so KillProcess is a
preferred mechanism.
"Christian Kesselheim via .NET 247" <anonymous@dotnet247.com> wrote in
message news:%23QXcJU9nEHA.2096@TK2MSFTNGP15.phx.gbl...
Hi!
Quite recently, I've been facing the situation of having to wrap up a
(buggy) third-party activex control in .NET in order to expose its
functionality via http webservices. After some unpleasant experiments
involving AppDomain's, Thread.Abort(), W32 TerminateThread(), I had
everything working exactly the way I wanted it (clean AppDomain unload in
case of an segfaults, etc), except for the rare case in which the OCX itself
decided to go for some endless loop and my thread never returned from
unmanaged code.
After spending some time investigating different newsgroups, etc, it occured
to me that there really was no way of terminating a thread within unmanaged
code in the current version of the .NET framework (1.1). Nevertheless, since
I'm not willing (nor able) to throw in the towel yet, I'm still hunting for
the best possible solution to my particular problem.
Do you think wrapping the nasty OCX into another instance of
System.Diagnostics.Process, handling all communication via .NET Remoting and
invoking Process.Kill when necessary would meet my needs, perhaps?
Thnx in advance. Regards,
Chris
--------------------------------
From: Christian Kesselheim
-----------------------
Posted by a user from .NET 247 (http://www.dotnet247.com/)
<Id>LhyLycsvCkGPlL89p7Dx8g==</Id>
- Next message: Jonathan Pierce: "Re: Decompiler.NET reverse engineers your CLS compliant code"
- Previous message: Flare: "(IOC and AOP (Aspect oriented programming)"
- In reply to: Christian Kesselheim via .NET 247: "Thread.Abort() vs. Unmanaged Code"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|