 |
Author |
Topic: Threads...a no no? (Read 554 times) |
|
Eben Eliason
Guest
|
Threads...a no no?
« on: May 3rd, 2004, 11:02am » |
|
Presently I have a class implementing the Thread interface. This class itself works fine, although it causes other issues. I'm aware of race conditions and deadlock, both of which I have been able to successfully avoid. Furthermore, I can know with absolute certainty that my threads terminate and are not left hogging up system resources. That said, here's the problem:
In order to terminate the threads, I have implemented the applet's stop() method. My implementation contains but one line of code:
myThread = null;
The only problem with implementing stop() is that apparently whatever thread is responsible for transferring System.out to the processing window never terminates...any print() statement inside void loop() prints forever, even after the applet closes.
I'm supposing that by implementing stop() myself I've overwritten some default version, perhaps? Not sure...anyway, why does this happen, and is there any reasonable way around it? I NEED the stop() method to terminate my own threads.
Thanks in advance!
-Eben
|
|
|
|
|
justo
|
Re: Threads...a no no?
« Reply #1 on: May 3rd, 2004, 11:45am » |
|
your code, in java, subclasses BApplet, and any methods you write with exactly the same signature as a method in BApplet will be overridden.
so if yourApplet.stop() is called normally, it calls the default version of stop(), which is found in the BApplet code. But if you override it, your version is called instead (hopefully this explanation makes sense...writing this at 530am...).
so, to answer your question, its as simple as explicitly calling BApplet's version of stop() with a
super.stop();
from your stop() method (after setting myThread = null). super is a reference every object has to its direct super class for cases like this.
|
|
|
|
|
arielm
|
Re: Threads...a no no?
« Reply #2 on: May 3rd, 2004, 12:01pm » |
|
on May 3rd, 2004, 11:45am, justo wrote:| from your stop() method (after setting myThread = null). super is a reference every object has to its direct super class for cases like this. |
|
just a tiny addition: super.stop() must be the first statement in the overriding method otherwise a normal java compiler should scream...
|
Ariel Malka | www.chronotext.org
|
|
|
justo
|
Re: Threads...a no no?
« Reply #3 on: May 3rd, 2004, 1:52pm » |
|
does it? i couldnt remember...i thought that was only for constructors.
the reason i said put super.stop() afterwards is that it should stop the graphics thread before you were able to get rid of your own...i was thinking that would cause some problems, but now that i think about it, it really wouldnt...stop() is completed before the VM exits. so either way should be fine, *if* you are able to put super.stop() in any order you like.
i'll check it out later.
|
|
|
|
|
arielm
|
Re: Threads...a no no?
« Reply #4 on: May 3rd, 2004, 2:24pm » |
|
oops, yep, i was wrong: the rule i was mentionning about "super" is only for constructors!
|
Ariel Malka | www.chronotext.org
|
|
|
Eben Eliason
Guest
|
Re: Threads...a no no?
« Reply #5 on: May 3rd, 2004, 4:41pm » |
|
Thanks guys!
Makes perfect sense and works like a charm. A call to super definitely hadn't even crossed my mind.
|
|
|
|
|
fry
|
Re: Threads...a no no?
« Reply #6 on: May 4th, 2004, 12:53am » |
|
hm, i guess this isn't documented anywhere as yet.. i'll make a note to see it get documented.
|
| « Last Edit: May 4th, 2004, 12:53am by fry » |
|
|
|
|
fry
|
Re: Threads...a no no?
« Reply #7 on: Jul 15th, 2004, 4:44pm » |
|
we'll add an example for megabucket that uses threads the "proper" way so hopefully that'll clear up some confusion.
|
|
|
|
|
|
