Thread.stop makes thread unabled to be signalled

B

Benji

I'm using Thread.stop() and running into problems. Just to get it out of
the way now, yes, I know it's deprecated, no, I can't use inturrupt.
I'm writing a student code autograder, so I can't guarentee anything
about the student code. This is adversarial programming. =)

The problem is that I can call stop() on a thread, and catch the
ThreadDeath that gets generated, and the thread *seems* to be just fine,
until I wait on a monitor. The object's monitor is definitely signalled,
but the thread never wakes up. It seems that Thread.stop() does more
than it says, because there is nothing about the *monitor* state that is
corrupted, it is that individual thread. (The other threads in the system
can get notified just fine - it's just the thread that was stopped) The
API makes it sound like the only bad state the thread gets in to is that
an unexpected exception can cause inconsistent state in the program - but
the exception isn't even propagating into my code - it's entirely in
student code, so at least according to the documentation, nothing should
be in a bad state.

Is there any way to get around this, or does Thread.stop() make the thread
unusable, and should I just respawn the thread? (I've already done the
latter - I was just curious as to what was going on)
 
A

Andrew Thompson

Benji said:
I'm using Thread.stop() and running into problems. Just to get it out of
the way now, yes, I know it's deprecated, no, I can't use inturrupt.
I'm writing a student code autograder, so I can't guarentee anything
about the student code. This is adversarial programming. =)

You might 'exec' them in a different JVM, then kill the
process. I suspect it would be far more 'complete' than
calling Thread.stop().

(Sorry, I have no actual experiences with processes, just
going on what I've seen/heard about the group)
 
R

Roedy Green

I'm writing a student code autograder, so I can't guarentee anything
about the student code. This is adversarial programming. =)

for this I think you would need two jvms. One jvm just monitors the
other to make sure it is still alive and sane and grading yet another
student program. The interface could be as simple as a project number
now grading on disk. If the student grader JVM dies, it spawns a new
one, telling it to pick up AFTER the project was last grading.


Every project gets a fresh thread. If you want to judge speed, things
get more complicated to make it fair.
 
B

Benji

Andrew said:
You might 'exec' them in a different JVM, then kill the
process. I suspect it would be far more 'complete' than
calling Thread.stop().
(Sorry, I have no actual experiences with processes, just
going on what I've seen/heard about the group)

Well, I'm getting fine "stop this thread from running" behavior. What I
was really hoping that I could do was be able to catch the ThreadDeath
before it propagates all the way up the stack, and continue execution
without having the thread damaged (as it apparently is)

I suppose it's not a very common occurrence, so it doesn't hurt to
spawn another thread in the case that I have to kill off a thread, but
the reason it concerned me was that I'm thinking that I may run in to
problems later with the way I'm currently doing it. I still have the
thread do some work when it catches the ThreadDeath, and I'm afraid
that there may be a bug introduced because of whatever this inconsistency
is. (So I was really more looking for someone to shed light on why
exactly the thread will not receive a notifyAll, and if that's the only
strange behavior I would see from a thread that has had stop called on
it)
 
B

Benji

Roedy said:
see http://mindprod.com/jgloss/thread.html and look for the
StoppableThread download.

I'm pretty sure that won't work. The whole reason I need to be stopping
the thread is that a student's code may go into an infinite loop. From
the description, it's basically just using good design to make stop
unnecessary. I can't really use good design, since I'm running arbitrary
code that I haven't written.
 
A

Andrew Thompson

Benji said:
..(So I was really more looking for someone to shed light on why
exactly the thread will not receive a notifyAll, and if that's the only
strange behavior I would see from a thread that has had stop called on
it)

Cool. I'll hush up and see what the thread gurus have to add..

[ I have done a few projects that involved running other
people's code (of untrusted origin - guaranteeing no
special interface), so I appreciate that you sometimes
need to do 'unconventional/unusual' things in those cases. ;-) ]
 
B

Benji

Roedy said:
tell your students as part of the exercise they must call some
stopping method you provide in the innermost loop.

well...

If you have a class with 900 students in it, it's a pretty good bet that
enough of them are going to disobey anything you tell them to make it
annoying. I'm writing an API that would ideally be able to be included
in a web submission framework. Wouldn't want to have a hung thread for
every annoying student.

plus, this is an intro to CS class...they don't even teach them what
methods are until a bit in to the class - it's not going to fly to make
the students have correct threading code in their program. I can't even
get the professor to let me force the students to conform to enough of
an interface to guarentee that I won't have to reload their class every
time between runs of their main method.

So, that being said, there's no clean way I can get around this. My
options are really either using Thread.stop(), or creating another JVM.

does anyone know if there's a clean way to invoke a child JVM? Like...
maybe a way to get a lighter weight solution than invoking a separate
JVM...but cleaner than stopping a thread?
 
B

Benji

Roedy said:
You might find that cute. I don't.

Well, I didn't find your attribution line either, but you don't see me
getting beligerant about it.

If you thought I was actually saying that you were high on whiteboard
markers, as opposed to it just being my normal attribution line, I'm
sorry that I offended you, and hope that whatever else it is that's
bothering you and making you cranky right now goes better for you. :eek:)

Hope you have a good day.
 
B

Benji

Roedy said:
You might find that cute. I don't.

Well, I didn't find your attribution line cute either, but you don't
see me getting beligerant about it.

If you thought I was actually saying that you were high on whiteboard
markers, as opposed to it just being my normal attribution line, I'm
sorry that I offended you, and hope that whatever else it is that's
bothering you and making you cranky right now goes better for you. :eek:)

Hope you have a good day.
 
A

Andrew Thompson

Benji said:
Well, I didn't find your attribution line cute either, but you don't
see me getting beligerant...

....LOL!

Are you new to usenet newsgroups?

[ As an aside, Roedy commonly has little knowledge of who
wrote what. For that reason, he uses 'wrote or quoted',
since people can get quite irate on the occasions he
incorrectly attributes something to a person.

I suspect Roedy would really prefer to just quote the text
to which he is replying. But other people dislike that
very much. ]
 
R

Roedy Green

Roedy Green, while high on whiteboard markers, wrote:

You can insult your friends that way and get away with it, but if you
do it to random strangers, you are asking for trouble.

Hint: don't go into a black neighbourhood wearing a "niggers are fags"
tee shirt.
 
R

Roedy Green

If you have a class with 900 students in it, it's a pretty good bet that
enough of them are going to disobey anything you tell them to make it
annoying.

Of course. But it does not matter. You give them a low grade. Your
system can still recover, albeit more awkwardly by killing the entire
jvm.
 
R

Roedy Green

If you thought I was actually saying that you were high on whiteboard
markers, as opposed to it just being my normal attribution line, I'm
sorry that I offended you, and hope that whatever else it is that's
bothering you and making you cranky right now goes better for you. :eek:)

You would not talk to a police officer, your prof, even a grocery
clerk that way you little twerp.

You will not get any help from me again unless you trick my killfile
filter and I fail to notice.
 
M

Mike Schilling

Roedy Green said:
You can insult your friends that way and get away with it, but if you
do it to random strangers, you are asking for trouble.

Hint: don't go into a black neighbourhood wearing a "niggers are fags"
tee shirt.

Or a redneck gay neighborhood.
 
C

Chris Uppal

Benji said:
does anyone know if there's a clean way to invoke a child JVM?
Yes.

Like...
maybe a way to get a lighter weight solution than invoking a separate
JVM...but cleaner than stopping a thread?

There isn't any way that isn't inherently as expensive as starting java.exe (or
equivalent). Not even if you drop down to the JNI level.

BTW if you were serious about "adversarial programming" (or sufficiently
intimidated by the terrors of the unknown) then it might be worth running the
students' code in a sandbox of some kind -- if you aren't doing so already...

As to your original question. I don't know the specific answer, but I suggest
that Thread.stop() is more dangerous than you seem to think. Think of it as
leaving /the entire system/ in an undefined state, since that (in the absence
of detailed technical analysis of the actual implementation[*]) is what it
does.

([*] The actual implementation, of course, being subtle and complex, and by no
means susceptible to "common sense" intuition.)

-- chris
 
C

Chris Smith

Benji said:
I'm using Thread.stop() and running into problems. Just to get it out of
the way now, yes, I know it's deprecated, no, I can't use inturrupt.
I'm writing a student code autograder, so I can't guarentee anything
about the student code. This is adversarial programming. =)

The problem is that I can call stop() on a thread, and catch the
ThreadDeath that gets generated, and the thread *seems* to be just fine,
until I wait on a monitor. The object's monitor is definitely signalled,
but the thread never wakes up.

Yep. If you read about why Thread.stop() is deprecated, you'll see that
its unavoidable potential to cause deadlocks in native code is one major
reason. Ending that thread is not necessarily good enough. You're
still taking a big chance.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
B

Benji

Andrew said:
Are you new to usenet newsgroups?

Nope. First time in 4 years that I've had anyone get upset about that
attribution line. I had a professor pretend he was upset about it just
to see how I would react. =) (not *that* was funny...)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,734
Messages
2,569,441
Members
44,832
Latest member
GlennSmall

Latest Threads

Top