jQuery in Action, 2nd edition*
The moose likes Java in General and the fly likes depricated mathod stop(), no alternate?? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "depricated mathod stop(), no alternate??" Watch "depricated mathod stop(), no alternate??" New topic
Author

depricated mathod stop(), no alternate??

Sandeep Jindal
Ranch Hand

Joined: Aug 25, 2003
Posts: 180
Dear All,
I know that Thread.stop() is depricated because of deadlick problems. And the alternate to this is givenm normally as
public void run(){
while(isStop==false){
//do blah-blah
}
}
public void stopThread(){
isStop=false;
}

But what i want is to stop the thread immidealty when i call the stop method. e.g my run is
public void run(){
//do blah 1
//do blah 2
//do blah 3
//do blah 4
}
So should i check if stop isStop=false after every blah.. or there is some alternate? If answer is no, then Sun is doin gr8 injustice with me cause my run method is too large containing a lot of sleeps and lot of method calls.

Regards
Sandeep Jindal
:roll:


SCJP 5.0
http://sites.google.com/site/duddlutechnologies/home
Joe Ess
Bartender

Joined: Oct 29, 2001
Posts: 8843
    
    7

Originally posted by Sandeep Jindal:
Dear All,
I know that Thread.stop() is depricated because of deadlick problems. And the alternate to this is given normally as. . .



But what i want is to stop the thread immidealty when i call the stop method. e.g my run is
public void run(){
//do blah 1
//do blah 2
//do blah 3
//do blah 4
}

I would argue that you are attempting to exercise conditional control over your program flow through the use of Thread.stop(). It would make sense to replace what you are trying to do with Thread.stop() with a boolean and check it before each "blah" in this case.

. . .Sun is doin gr8 injustice with me cause my run method is too large containing a lot of sleeps and lot of method calls.

Only a poor carpenter blames his tools.


"blabbing like a narcissistic fool with a superiority complex" ~ N.A.
[How To Ask Questions On JavaRanch]
Sandeep Jindal
Ranch Hand

Joined: Aug 25, 2003
Posts: 180
Dear Joe,
Thanks for the reply. But I did not get u well.
My task is to run a thread(separte from main), that will do so many blah-blah with different time intervals in between each blah. This(sort of sequence) is too large(containg too steps(blah) and too many sleeps).
Now i want to stop at a particular step(blah) whenever a definte event occured at my main thread(say any other thread).
If Thread.stop() would not be depracated(cause of deadlock problems) , that would really help me to stop the thread "immideatly" after the stop() method is called.
But the alternate i m using is to check for some boolean (isStop in my example) at every step.


This alternate works fine, but probably not a very gud (approach)architechure. So i just wanna know if there is some alternate for that?? Alternativly i have to advice Sun to work more on threads.
Regrds
Sandeep Jindal
Joe Ess
Bartender

Joined: Oct 29, 2001
Posts: 8843
    
    7

Originally posted by Sandeep Jindal:

This alternate works fine, but probably not a very gud (approach)architechure.

I don't see anything wrong with your approach. Even if Thread.stop() were not depreciated I think it would make more sense to approach your problem in this manner. Let's say you use Thread.stop() to control the execution of your run() method. Another programmer goes looking at your code and can't understand why blah3 and blah4 did not execute in a particular run. In another run Thread.stop() kills the thread before blah2 executes. In another run, all 4 blahs run fine. This programmer could go crazy before he figures out that Thread.stop() is being called somewhere in another thread/class. That is a bad architecture. I define a good architecture as one that:
1. Works
2. Can be seen to work (i.e. by another programmer)
They way you have it written now it is quite plain that some other thread told this thread not to execute any more methods and exit. The other programmer would see that a flag was set by another thread and be able to quickly turn his attention to the stopThisThread() call in another thread/class. It may not be pretty, but Thread.stop() is far uglier.
Sandeep Jindal
Ranch Hand

Joined: Aug 25, 2003
Posts: 180
Dear joe,
Thanks a lot for your response. That answers my question.
But just for discussion sake i want to ask one more question on this only..
As I have told that my run method is really big(roughly 20 method calls, different checks, and so many sleeps). And at every step i m writing:
if(isStop) return;
Just this thing sound bad to me. I mean java provides a very sophisticated Error Hadnling(try and catch), we dont have to write on error do this
at every line of code. And things like that only make java easy and good. On that point of view, it seems very odd that u r writing the same code
if(isStop) return; 30 times(as in my case). I know that its working, and easy to understand by other user, but not gud architechtrure. Cause to ur defination i would like to add one more line..
- In gud architecture, no code repition is there.
Moreover, if another progarmmer knows Threads, then he must know the Thread.stop()(if it wont be depricated) and could find the reason of execution of limited blahs.
And can u please flash some light on destroy() method. This method conatins nothing, and still not depricated? Is it for future purposes or any other reasons. I mean, can it help me any way for my code?
regards
Sandeep Jindal
Joe Ess
Bartender

Joined: Oct 29, 2001
Posts: 8843
    
    7

Originally posted by Sandeep Jindal:
Cause to ur defination i would like to add one more line..
- In gud architecture, no code repition is there.

What you have is not repetition. Before each method call you want to make sure someone hasn't canceled the operation. There really isn't a shortcut to doing the comparisons short of someone writing a class called ReadUsersMind.
You could streamline this code if that's what you are worried about:

But it will do the same number of comparisons as your old code with the added overhead of creating a loop and checking the counter variable before every iteration. You mentioned you had lots of sleeps in your code, so this shouldn't be a concern, just mentioning it because "There An't No Such Thing As A Free Lunch"

Moreover, if another progarmmer knows Threads, . . . could find the reason of execution of limited blahs.

I wouldn't want to be that guy! Seriously, unless you documented it well and often that you were allowing another thread to kill another one off it would be nearly impossible to gain that knowledge from watching the program run. ESPECIALLY if the Thread.sleep() calls removed the thread death from the user/program interaction that triggered it!

And can u please flash some light on destroy() method.

It isn't implemented, so I don't think it's an option. I sure don't like the sound of this:

Any monitors it has locked remain locked

Deadlock city!
Sandeep Jindal
Ranch Hand

Joined: Aug 25, 2003
Posts: 180
Thanks joe ,
I got your point and the nice explaination . But, I have heard that Sun is working on threads in a good manner and will definetly come up with gud changes and make the life of a programmer easier .
I have one more doubt on notify and wait, that i will ask in some different thread cause the Curruent topic name wont be appropiate for that discussion.
Well, i want to know more bout the destroy()(u have not expalined it earlier), that destroy method is not implemented, then why it is there? Is it for future purposes only? and if there is some other use of that please explain bout it, means when should it be used?

Thanks and regards
Sandeep Jindal
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34


Is it for future purposes only?

More like past purposes only. It turns out that it's not even possible to implement on all platforms, and it's never a good idea, so it just sits there, unimplemented. It will never be implemented.


[Jess in Action][AskingGoodQuestions]
Sandeep Jindal
Ranch Hand

Joined: Aug 25, 2003
Posts: 180
Thanks Ernest and Joe,
thanks for the nice discussion.

but one thing always bothers me that if detroy() is never implemented and will never be implemented then why sun has not deleted it or atleast make it depriacted. These sort of confusing methods confuse the poor programmers like me . Can i suppose that this methos is soon goin to be atleast depricated??
Regards
Sandeep Jindal
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Can i suppose that this methos is soon goin to be atleast depricated??
Yes. Of course it took Sun over four years to address this really obvious bug after it was pointed out to them, but it looks like they are finally doing something about it. :roll:


"I'm not back." - Bill Harding, Twister
Sandeep Jindal
Ranch Hand

Joined: Aug 25, 2003
Posts: 180
Dear Jim,
Thanks for ur answer.

Sandeep
 
 
subject: depricated mathod stop(), no alternate??
 
Similar Threads
Thread.stop() depricated.. alternate??
Stopping a Thread
stopping the thread
repost awt quiting
how to make simple sleep()