Let the third party fix their code, this is all you can do. Calling
Thread.Abort on a thread other than the currently executing thread is BAD,
you don't know what the the thread is actually doing, it's even possible
that he is blocked in unmanaged code, in which case a Thread.Abort won't
help you anyway.
Willy.
"Steve" <sk**@skle.com> wrote in message
news:uf**************@TK2MSFTNGP02.phx.gbl...
| My fault Nicholas, I should have been more specific. My LongMethod()
| function isn't mine, I can't change it. It's a 3rd party library. I had
| said that I can't check for the stop flag, but I didn't say why.
Apologies.
|
| -Steve
|
|
| "Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote
in
| message news:uo**************@TK2MSFTNGP05.phx.gbl...
| > Steve,
| >
| > I don't see why you can't check for the stop flag. Basically,
instead
| > of checking the while loop for true, check the flag, like so:
| >
| > // In class.
| > private boolean continueLoopLock = new object();
| > private boolean continueLoop;
| >
| > private bool ContinueLoop
| > {
| > get
| > {
| > lock (continueLoopLock)
| > {
| > // Return the value.
| > return continueLoop;
| > }
| > }
| > set
| > {
| > lock (continueLoopLock)
| > {
| > // Set the value.
| > continueLoop = value;
| > }
| > }
| > }
| >
| > // In the class.
| > Thread t = new Thread(new ThreadStart(LongMethod));
| > ContinueLoop = true;
| > t.Start();
| >
| > private void LongMethod()
| > {
| > while (ContinueLoop)
| > {
| >
| > }
| > }
| >
| > Then, when you want it to stop, you just set ContinueLoop to false.
| >
| > The property is there to make it easier to encapsulate the locking
| > logic, since you will have two threads accessing this at the same time.
| >
| >
| > --
| > - Nicholas Paldino [.NET/C# MVP]
| > -
mv*@spam.guard.caspershouse.com
| >
| > "Steve" <sk**@skle.com> wrote in message
| > news:OS**************@TK2MSFTNGP05.phx.gbl...
| >> Hi Nicholas,
| >>
| >> I agree that I should not create the thread in the ctor, I changed that
| >> after reading your post. I also understand what you mean about the
stop
| >> flag being checked, it's like Jon Skeet's article that Larry posted.
| >>
| >> My situation is maybe a bit unique in that my thread is stuck in a
method
| >> call that can't check for the stop flag. I would like to kill the
thread
| >> gracefully, but I'm not sure if I can.
| >>
| >> Basically my situation is:
| >> Thread t = new Thread( new ThreadStart(LongMethod) );
| >> t.Start();
| >>
| >> private void LongMethod()
| >> {
| >> while(true)
| >> {
| >> //...
| >> }
| >> }
| >>
| >>
| >> Any other suggestions?
| >>
| >> Thanks for the post!
| >> -Steve
| >>
| >>
| >>
| >>
| >> "Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com>
wrote
| >> in message news:eK**************@TK2MSFTNGP02.phx.gbl...
| >>> Steve,
| >>>
| >>> I think you are going about this the wrong way. You should rarely
| >>> call Stop on a thread in order to stop processing on it. Rather, you
| >>> are better off having some sort of shared variable which the thread
will
| >>> check periodically to see if it should terminate. If the variable is
| >>> set, then the code in the thread will just exit, and the thread will
| >>> die.
| >>>
| >>> Also, you should create a new thread when you call StartTest, not
| >>> when you create your class. You should use a new thread each time.
You
| >>> can choose to store it on the class level, but the only reason I can
see
| >>> doing so would be to determine if an operation is running.
| >>>
| >>> Hope this helps.
| >>>
| >>>
| >>> --
| >>> - Nicholas Paldino [.NET/C# MVP]
| >>> -
mv*@spam.guard.caspershouse.com
| >>>
| >>> "Steve" <sk**@skle.com> wrote in message
| >>> news:uR*************@TK2MSFTNGP05.phx.gbl...
| >>>> I'm having a problem with my Thread usage and I think the general
| >>>> design of how I'm working with them. My UI class calls a method in
| >>>> another class that does a lot of work. That "worker" class looks
| >>>> something like this(pseudo code):
| >>>> class WorkerClass
| >>>> {
| >>>> Thread _listenerThread;
| >>>>
| >>>> public WorkerClass()
| >>>> {
| >>>> _listenerThread = new Thread( new
ThreadStart(ListenForInput) );
| >>>> _listenerThread.IsBackground = true;
| >>>> _listenerThread.Name = "Worker Listener Thread";
| >>>> }
| >>>>
| >>>> public void StartTest()
| >>>> {
| >>>> // do some quick stuff, then start the listener thread
| >>>> _listenerThread.Start();
| >>>> }
| >>>>
| >>>> private void ListenForInput()
| >>>> {
| >>>> // make call to external library that
| >>>> // won't return until a condition is met
| >>>> }
| >>>>
| >>>> public void CancelTest()
| >>>> {
| >>>> _listenerThread.Stop();
| >>>> }
| >>>> }
| >>>>
| >>>>
| >>>> That is pretty close to what I have. So, I have a couple issues that
| >>>> I'm dealing with. If I have run StartTest() once and call it again
| >>>> later (I handle when it can be called, ListenForInput raises an event
| >>>> when it's done) the _listenerThread's ThreadState is 'Background' so
a
| >>>> subsequent call to Start() throws an exception.
| >>>>
| >>>> I figured I was having this behavior because the thread is a member
of
| >>>> the class rather than local to a method, but I need to have it as a
| >>>> member so that I can cancel it from the UI if a user wishes.
| >>>>
| >>>> I added some code to the end of ListenForInput() that would call
Stop()
| >>>> on the thread, but that seems dangerous to kill the thread you are
| >>>> running on? In fact, is it safe for a process to modify ANYTHING
about
| >>>> a thread it's running on? Like priority or ThreadState?
| >>>>
| >>>> Basically I'm just not sure how to design what I need. The above
class
| >>>> is an accurate model of what I'm after. Most of the threading
examples
| >>>> I have seen online or too simple and don't cover stuff like this.
| >>>>
| >>>> Thanks for reading, I hope someone has some pointers for me.
| >>>> -Steve
| >>>>
| >>>
| >>>
| >>
| >>
| >
| >
|
|
