473,726 Members | 2,021 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Thread.Abort

Hi

I wrote an application server (a remoting sinlgeton), where processes must
be stopped in very rare cases, done thru a Thread.Abort(). Occasionally, and
only after a Thread.Abort(), this component becomes instabile, throwing a
Windows like error (access violation on 0x00000002), not an framework
exception. The component and all of its subcomponents are 100% managed code.
What could go wrong with Thread.Abort()?

Thanks for any hints.
Urs
Nov 17 '05 #1
18 5857
Thread.Abort() is a method you should only call to abort the current thread,
the only valid reason to call it on another thread is when you intend to
unload the application domain anyway.
There are numerous things that can go wrong when aborting another thread,
Please search the archives, this has been discussed several times before in
this and other NG's.

Willy.

"Urs Vogel" <uv****@msn.com > wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..
Hi

I wrote an application server (a remoting sinlgeton), where processes must
be stopped in very rare cases, done thru a Thread.Abort(). Occasionally,
and only after a Thread.Abort(), this component becomes instabile,
throwing a Windows like error (access violation on 0x00000002), not an
framework exception. The component and all of its subcomponents are 100%
managed code. What could go wrong with Thread.Abort()?

Thanks for any hints.
Urs

Nov 17 '05 #2
Is your app server interacting with any system resources? That could cause
this.
Look into ManualResetEven t class, it's a call that can signal a running
thread that something important happened (user clicked cancel for example)
and it can abort gracefully. I remember reading an article with code samples
on how to do that, can't remember where.

"Urs Vogel" wrote:
Hi

I wrote an application server (a remoting sinlgeton), where processes must
be stopped in very rare cases, done thru a Thread.Abort(). Occasionally, and
only after a Thread.Abort(), this component becomes instabile, throwing a
Windows like error (access violation on 0x00000002), not an framework
exception. The component and all of its subcomponents are 100% managed code.
What could go wrong with Thread.Abort()?

Thanks for any hints.
Urs

Nov 17 '05 #3
Or upgrade to .NET Framework 2.0 where this issue has been fixed!

On Tue, 16 Aug 2005 17:27:27 +0200, "Willy Denoyette [MVP]"
<wi************ *@telenet.be> wrote:
Thread.Abort () is a method you should only call to abort the current thread,
the only valid reason to call it on another thread is when you intend to
unload the application domain anyway.
There are numerous things that can go wrong when aborting another thread,
Please search the archives, this has been discussed several times before in
this and other NG's.

Willy.

--
http://www.kynosarges.de
Nov 17 '05 #4

"Christoph Nahr" <ch************ @kynosarges.de> wrote in message
news:dn******** *************** *********@4ax.c om...
Or upgrade to .NET Framework 2.0 where this issue has been fixed!

On Tue, 16 Aug 2005 17:27:27 +0200, "Willy Denoyette [MVP]"
<wi************ *@telenet.be> wrote:
Thread.Abort( ) is a method you should only call to abort the current
thread,
the only valid reason to call it on another thread is when you intend to
unload the application domain anyway.
There are numerous things that can go wrong when aborting another thread,
Please search the archives, this has been discussed several times before
in
this and other NG's.

Willy.

--
http://www.kynosarges.de


True, but I don't believe all issues are fixed, as far as I know
Thread.Abort() will no longer be injected while running exception handling
code blocks, but will be delayed until catch/finally blocks exit, but the
issues remain when executing outside try/catch/finally blocks.

Willy.

Nov 17 '05 #5
On Wed, 17 Aug 2005 10:44:04 +0200, "Willy Denoyette [MVP]"
<wi************ *@telenet.be> wrote:
True, but I don't believe all issues are fixed, as far as I know
Thread.Abort () will no longer be injected while running exception handling
code blocks, but will be delayed until catch/finally blocks exit, but the
issues remain when executing outside try/catch/finally blocks.


What issues would that be? The interruption of catch/finally was the
only one that I'm aware of. Certainly Thread.Abort will stop your
thread asynchronously, interrupting whatever it is doing outside of
exception handling -- but that's the whole point of it, after all.
--
http://www.kynosarges.de
Nov 17 '05 #6

"Christoph Nahr" <ch************ @kynosarges.de> wrote in message
news:s9******** *************** *********@4ax.c om...
On Wed, 17 Aug 2005 10:44:04 +0200, "Willy Denoyette [MVP]"
<wi************ *@telenet.be> wrote:
True, but I don't believe all issues are fixed, as far as I know
Thread.Abort( ) will no longer be injected while running exception handling
code blocks, but will be delayed until catch/finally blocks exit, but the
issues remain when executing outside try/catch/finally blocks.
What issues would that be? The interruption of catch/finally was the
only one that I'm aware of. Certainly Thread.Abort will stop your
thread asynchronously, interrupting whatever it is doing outside of
exception handling -- but that's the whole point of it, after all.
--

The general issue of reliability remains as long as one thread can
arbitrarily inject an abort into another thread. For example, if a static
constructor is aborted it renders that type unusable within that appdomain -
an instance of that type cannot be constructed. Outside of constrained
execution regions an abort can be raised between any two lines of machine
code, so it is very difficult to determine if code is correct.

This may not be a problem if you are expecting this behavior, but it is
easy for the unwary to make assumptions that are incorrect.

http://www.kynosarges.de

Nov 17 '05 #7
On Wed, 17 Aug 2005 18:26:25 -0500, "David Levine"
<no************ ******@wi.rr.co m> wrote:
The general issue of reliability remains as long as one thread can
arbitrarily inject an abort into another thread. For example, if a static
constructor is aborted it renders that type unusable within that appdomain -
an instance of that type cannot be constructed.
You're right, it's still possible to abort a static constructor.
However, I believe that's only a problem if a new thread accesses such
types with static ctors for the first time. It's a potentially nasty
issue that should be fixed; but it shouldn't affect your typical
background worker thread that only operates on existing data when the
program is already fully initialized.
Outside of constrained
execution regions an abort can be raised between any two lines of machine
code, so it is very difficult to determine if code is correct.
Sure, but since catch/finally is now left alone it's at least possible
to mitigate this issue with the appropriate constructs.
This may not be a problem if you are expecting this behavior, but it is
easy for the unwary to make assumptions that are incorrect.


Well, as I already said Thread.Abort is specifically intended for
asynchronously terminating another thread, so this behavior should be
expected by anyone who is using this facility. MT is and will remain
hard, and always requires that developers learn how it works and are
careful about their implementation. The behavior of Thread.Abort is
just another facet that we'll have to remember.
--
http://www.kynosarges.de
Nov 17 '05 #8

"Christoph Nahr" <ch************ @kynosarges.de> wrote in message
news:s9******** *************** *********@4ax.c om...
On Wed, 17 Aug 2005 10:44:04 +0200, "Willy Denoyette [MVP]"
<wi************ *@telenet.be> wrote:
True, but I don't believe all issues are fixed, as far as I know
Thread.Abort( ) will no longer be injected while running exception handling
code blocks, but will be delayed until catch/finally blocks exit, but the
issues remain when executing outside try/catch/finally blocks.


What issues would that be? The interruption of catch/finally was the
only one that I'm aware of. Certainly Thread.Abort will stop your
thread asynchronously, interrupting whatever it is doing outside of
exception handling -- but that's the whole point of it, after all.
--
http://www.kynosarges.de


Well, my point was that you shouldn't assume it's safe to continue
execution of code inside an AD that has been subject of an asynchronous
thread abort, that's the impression you gave by this "Or upgrade to .NET
Framework 2.0 where this issue has been fixed!". NO, you still have to
consider thread aborts as being initiated by AD unloads, asynchronous thread
aborts initiated by a call to Thread.Abort() in your code is still bad,
unless it's immediately followed by an AD unload.

Now what's been solved, is that the CLR no longer injects (asynchronous)
thread aborts while executing inside class contructors, finally and catch
blocks and while running unmanaged code. If an abort is requested while
executing inside one of these, the CLR will inject as soon as you exit from
these regions, it means that you are assured that static's are correctly
initialized and that your exception handlers will run. So now at least you
have a fair chance to fix up your cross-AD state, this covers state
acquired/mutated inside a try block, so you can continue to run your other
AD and possibly recycle the offending AD without being forced to recycle the
process (like it's been done in ASP.NET).
However , you still have to consider state acquired outside a try block,
where a thread abort can occur between any machine instruction.

That means that following will leak a handle when the abort occurs after the
handle has been acquired but before the try block has entered.

IntPtr handle = AcquireHandle(. ...)
try {
// use add...
....}
finally {
FreeUnmanaged(h andle);
}
Now, suppose handle is a File handle, when you recycle the AD domain and try
to open same File (or simply try to open the file in another process/AD) you
might get a sharing violation exception because the file wasn't closed as
the process didn't exit.

You can solve this by pairing the allocation/de-allocation unmanaged
resources (handles, memory etc...) inside the try/finally, or by using a
SafeHandle wrapper for handles.

But consider this ...
using(SomeExpen siveResource res = new(....))
{
....
}
a thread abort can be raised after the constructor invocation but before
the assignment of res, as this abort occurs outside the try block, finally
never runs and Dispose is never called. (Note that res == null, so Dispose
could never be called anyway).
Hopefully SomeExpensiveRe source has a Finalizer or you'll leak resources,
that's one of the reasons why IDisposable objects should have a destructor
(Finalize).

Willy.


Nov 17 '05 #9
Is the Thread Abort injection postponed only till the catch/finally
block completes, or is it held back till the entire try block and it's
catch/finally blocks execute?

Regards
Senthil

Nov 17 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

14
5358
by: Daisy | last post by:
From this page: http://www.c-sharpcorner.com/2/mt_beginner1.asp Thread class's Abort method is called to kill a thread permanently. Make sure you call IsAlive before Abort. if ( thread.IsAlive ) { thread.Abort(); }
7
3291
by: Morris | last post by:
I want to abort a running thread, so I call MyThread.abort() function. My problem is this thread runs "almost" like a while(true) loop and I don't want the Abort() function interrupts the thread at any point in the thread. In fact, I have a section of code needs to be "protected" from being interrupted. How can I make sure Abort() will not land anywhere winthin this block? In other words, the Abort() must wait until this block of code is done...
20
3028
by: Doug Thews | last post by:
I ran into an interesting re-pain delay after calling the Abort() method on a thread, but it only happens the very first time I call it. Every time afterward, there is no delay. I've got a delegate inside the UI that I call to update the progress meter. I use the Suspend() and Abort() methods based on button events. I can watch the progress meter increase just fine when the thread is running. When I select Start, I enable the Cancel...
1
4473
by: benmorganpowell | last post by:
I have a small windows service which connects to a POP3 server at defined intervals, scans the available messages, extracts the required information and inserts the data into a SQL database. I am assuming that this is not an uncommon piece of software. I want to get an architecture that conforms as closely as possible with the recommendations from Microsoft on developing Windows Services, but to be honest I have found difficultly in...
2
4286
by: Mark Denardo | last post by:
I'm trying to abort a suspended thread, but I get a ThreadStateException: An unhandled exception of type 'System.Threading.ThreadStateException' occurred in mscorlib.dll Additional information: Thread is suspended; attempting to abort. I have a number or threads in my program - some running, some suspended. I hope I don't have to start the thread up again just to abort it??
6
5479
by: Joe HM | last post by:
Hello - I have a function that calls Thread.Abort() to stop a thread in a _Closed() Method of a GUI. The thread contains a blocking call on a TCP socket and that is the easiest way to stop that. This thread is also outputting strings in a RichTextBox and in some rare instances I get a System.NullReferenceException when I exit the GUI. It seems like the _Closed() Method calls Thread.Abort() and then continues closing down/disposing...
23
5708
by: Boltar | last post by:
Hi I'm writing a threading class using posix threads on unix with each thread being run by an object instance. One thing I'm not sure about is , if I do the following: myclass::~myclass() { : : do stuff
5
5077
by: andrew | last post by:
Hi, I have the following issue with the Thread.Abort(): The main thread creates a worker thread which waits on a process termination. void ThreadProc() { Process proc = proc.Start("notepad.exe");
6
2942
by: mehdi | last post by:
Hi folks, You know, the Thread class has got a method named Abort which according to the msdn: "Raises a ThreadAbortException in the thread on which it is invoked, to begin the process of terminating the thread. Calling this method usually terminates the thread." I've had a long discussion with someone on not to use the mentioned method unless under the most extreme cases. I believe that it's
1
9182
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
9120
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
8101
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
6702
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
4521
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
4785
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
3228
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
2639
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
2157
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.