 |
AppletTalk.com
Java discussions newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Ao
Guest
|
 Posted: Fri Nov 05, 2004 3:03 pm Post subject: Thread-question |
 |
|
Hi everybody,
when closing my program I would like to start a Thread which does some
cleaning up in the background, but opf course before exiting I need to
be sure, that this Thread has finished running...
How can I wait for that Thread to finish, the following code does work,
but freezes my UI...
....
private boolean cleanedUp = false;
....
public void programmBeenden() {
Thread cleaner = new Thread() {
public void run() {
// clean up some things...
cleanedUp=true;
}
}
cleaner.start();
// ... do some other stuff
// finally wait for cleaner to finish
while(!cleanedUp) {
try {
Thread.sleep(100);
} catch(InterruptedExecption iuE) {}
}
System.exit(0);
}
What else can I do to make sure that cleaner has finished without
freezing my UI.
Thanks, Aloys
|
|
| Back to top |
|
 |
Thomas Weidenfeller
Guest
|
| Posted: Fri Nov 05, 2004 3:31 pm Post subject: Re: Thread-question |
|
|
Please post to one group only. Your question is not that important.
Ao wrote:
| Quote: | How can I wait for that Thread to finish, the following code does work,
but freezes my UI...
|
There is some information about this in the comp.lang.java.gui FAQ. You
are blocking the EDT.
Maybe you also want to read about shutdown hooks, SwingWorker and the
Swing threading model in general.
Regarding the problem of waiting for a thread: Thread.join();
/Thomas
|
|
| Back to top |
|
|
shakahshakah@gmail.com
Guest
|
| Posted: Fri Nov 05, 2004 3:32 pm Post subject: Re: Thread-question |
|
|
FWIW, and depending on the what you are trying to accomplish, you may
not have to explicitly wait for the worker thread to finish. In the
absence of an explicit call to System.exit(), your application won't
exit until all (non-daemon) threads have exited.
|
|
| Back to top |
|
|
xarax
Guest
|
| Posted: Fri Nov 05, 2004 7:55 pm Post subject: Re: Thread-question |
|
|
<shakahshakah (AT) gmail (DOT) com> wrote
| Quote: | FWIW, and depending on the what you are trying to accomplish, you may
not have to explicitly wait for the worker thread to finish. In the
absence of an explicit call to System.exit(), your application won't
exit until all (non-daemon) threads have exited.
|
The AWT EDT is non-daemon, thus the call to System.exit()
is required to shutdown the JVM.
Just put the System.exit(0) call in the other
thread that performs the clean-up. Don't bother
with Thread.join() in the EDT; it will just hang
the GUI.
|
|
| Back to top |
|
|
hiwa
Guest
|
|
| Back to top |
|
|
Babu Kalakrishnan
Guest
|
| Posted: Sat Nov 06, 2004 7:00 am Post subject: Re: Thread-question |
|
|
Ao wrote:
| Quote: |
when closing my program I would like to start a Thread which does some
cleaning up in the background, but opf course before exiting I need to
be sure, that this Thread has finished running...
|
Runtime.getRuntime().addShutdownHook()
BK
|
|
| Back to top |
|
|
Yakov
Guest
|
| Posted: Sat Nov 06, 2004 12:33 pm Post subject: Re: Thread-question |
|
|
Ao <aloys.oberthuer (AT) gmx (DOT) net> wrote
| Quote: | Hi everybody,
when closing my program I would like to start a Thread which does some
cleaning up in the background, but opf course before exiting I need to
be sure, that this Thread has finished running...
|
If you want to exit your app only after some code is finished, do not
even bother with threads. Just create another method with required
code, and the last line of your program should be a call of this
method.
|
|
| Back to top |
|
|
Thomas G. Marshall
Guest
|
| Posted: Tue Nov 09, 2004 3:17 pm Post subject: Re: Thread-question |
|
|
Yakov coughed up:
| Quote: | Ao <aloys.oberthuer (AT) gmx (DOT) net> wrote in message
news:<cmg4jf$v33$02$1 (AT) news (DOT) t-online.com>...
Hi everybody,
when closing my program I would like to start a Thread which does
some cleaning up in the background, but opf course before exiting I
need to be sure, that this Thread has finished running...
If you want to exit your app only after some code is finished, do not
even bother with threads. Just create another method with required
code, and the last line of your program should be a call of this
method.
|
That is not going to work in general.
His "code" that you refer to could easily just be firing up a pile of GUI
and then do nothing more. Setting up the GUI is (usually) by nature
non-blocking, this leaves no particular good time for that last line of his
program to run.
The other suggestions in this thread are better.
--
http://www.allexperts.com is a nifty way to get an answer to just about
/anything/.
|
|
| Back to top |
|
|
Andy Flowers
Guest
|
| Posted: Tue Nov 09, 2004 6:44 pm Post subject: Re: Thread-question |
|
|
Have you thought about overriding finalize() in the objects you wish to have
some final clean up ?
"Ao" <aloys.oberthuer (AT) gmx (DOT) net> wrote
| Quote: | Hi everybody,
when closing my program I would like to start a Thread which does some
cleaning up in the background, but opf course before exiting I need to be
sure, that this Thread has finished running...
How can I wait for that Thread to finish, the following code does work,
but freezes my UI...
...
private boolean cleanedUp = false;
...
public void programmBeenden() {
Thread cleaner = new Thread() {
public void run() {
// clean up some things...
cleanedUp=true;
}
}
cleaner.start();
// ... do some other stuff
// finally wait for cleaner to finish
while(!cleanedUp) {
try {
Thread.sleep(100);
} catch(InterruptedExecption iuE) {}
}
System.exit(0);
}
What else can I do to make sure that cleaner has finished without freezing
my UI.
Thanks, Aloys
|
|
|
| Back to top |
|
|
Carl Howells
Guest
|
| Posted: Tue Nov 09, 2004 6:48 pm Post subject: Re: Thread-question |
|
|
Andy Flowers wrote:
| Quote: | Have you thought about overriding finalize() in the objects you wish to have
some final clean up ?
|
Bad idea. On most modern JVMs, finalizers seriously mess up garbage
collection. In fact, if the JVM can avoid it, it'll just *not* collect
objects with finalizers. It's not a very good way to get code run.
If you need post-collection cleanup of non-memory resources, remember
that PhantomReference is your friend.
|
|
| Back to top |
|
|
Stefan Schulz
Guest
|
| Posted: Tue Nov 09, 2004 6:52 pm Post subject: Re: Thread-question |
|
|
On Fri, 05 Nov 2004 16:03:42 +0100, Ao <aloys.oberthuer (AT) gmx (DOT) net> wrote:
| Quote: | What else can I do to make sure that cleaner has finished without
freezing my UI.
|
Since you are shutting down anyway, take a look at
Runtime.addShutdownHook()
--
Whom the gods wish to destroy they first call promising.
|
|
| Back to top |
|
|
Chris Uppal
Guest
|
| Posted: Wed Nov 10, 2004 9:16 am Post subject: Re: Thread-question |
|
|
Carl Howells wrote:
| Quote: | Bad idea. On most modern JVMs, finalizers seriously mess up garbage
collection.
|
I have to say that I find this implausible. Obviously finalisation adds
overhead to the GC operation, but that's because it's doing extra work --
/useful/ extra work -- but it sounds as if you mean something more than that.
Do you have any references ?
| Quote: | In fact, if the JVM can avoid it, it'll just *not* collect
objects with finalizers. It's not a very good way to get code run.
|
It's perfectly at liberty not to collect anything. But again you seem to be
going beyond that and stating that it (they) will discriminate against objects
with finalisers. Again, this sounds implausible. Do you have a reference for
it ?
(BTW I don't think finalisation is likely to be at all appropriate as a
solution to the OP's problem.)
-- chris
|
|
| Back to top |
|
|
John C. Bollinger
Guest
|
| Posted: Wed Nov 10, 2004 2:40 pm Post subject: Re: Thread-question |
|
|
Chris Uppal wrote:
| Quote: | Carl Howells wrote:
Bad idea. On most modern JVMs, finalizers seriously mess up garbage
collection.
I have to say that I find this implausible. Obviously finalisation adds
overhead to the GC operation, but that's because it's doing extra work --
/useful/ extra work -- but it sounds as if you mean something more than that.
Do you have any references ?
|
I haven't looked up references (yet) but my understanding is that Carl
is correct, if perhaps overly emphatic. Based only on the API docs and
JLS, one can argue that instances of classes that do not override
finalize() can be collected without actually invoking Object.finalize(),
as the VM can know that its Object.finalize() is specified to do
nothing. More importantly, however, it is possible for a finalize()
method to make the object it is invoked on reachable again (an odd state
indeed: finalized and reachable), so after finalizing an object with a
non-default finalizer, the GC must completely redo its reachability
analysis for that object. Naturally, that also affects the reachability
of objects to which the one in question holds references.
The VM must also keep track of whether or not reachable objects have
been finalized, because they are only ever finalized once (per
specification). That probably doesn't add much overhead, but it may
result in unexpected behavior when the second time an object becomes
unreachable it is discarded without its finalizer being invoked.
| Quote: | In fact, if the JVM can avoid it, it'll just *not* collect
objects with finalizers. It's not a very good way to get code run.
It's perfectly at liberty not to collect anything. But again you seem to be
going beyond that and stating that it (they) will discriminate against objects
with finalisers. Again, this sounds implausible. Do you have a reference for
it ?
|
That would be an implementation question, but I suspect that many Java
GC implementations indeed do exactly as Carl describes. It really is a
much bigger deal to collect an object with a non-default finalizer than
to collect other objects.
It might be a little too strong to say that Java's finalization
mechanism is broken, but I have never personally run into any task to
which it is suited. It is definitely a trap, because people --
especially those with experience in some other OO languages, such as C++
-- tend to make incorrect assumptions about how finalization works. It
has been said here before and it will be repeated again: a Java
finalizer is not at all the same thing as a C++ destructor.
John Bollinger
[email]jobollin (AT) indiana (DOT) edu[/email]
|
|
| Back to top |
|
|
Thomas G. Marshall
Guest
|
| Posted: Wed Nov 10, 2004 3:32 pm Post subject: Re: Thread-question |
|
|
John C. Bollinger coughed up:
| Quote: | Chris Uppal wrote:
Carl Howells wrote:
Bad idea. On most modern JVMs, finalizers seriously mess up garbage
collection.
I have to say that I find this implausible. Obviously finalisation
adds overhead to the GC operation, but that's because it's doing
extra work -- /useful/ extra work -- but it sounds as if you mean
something more than that. Do you have any references ?
I haven't looked up references (yet) but my understanding is that Carl
is correct, if perhaps overly emphatic. Based only on the API docs
and JLS, one can argue that instances of classes that do not override
finalize() can be collected without actually invoking
Object.finalize(), as the VM can know that its Object.finalize() is
specified to do nothing. More importantly, however, it is possible
for a finalize() method to make the object it is invoked on reachable
again (an odd state indeed: finalized and reachable), so after
finalizing an object with a non-default finalizer, the GC must
completely redo its reachability analysis for that object.
Naturally, that also affects the reachability of objects to which the
one in question holds references.
The VM must also keep track of whether or not reachable objects have
been finalized, because they are only ever finalized once (per
specification). That probably doesn't add much overhead, but it may
result in unexpected behavior when the second time an object becomes
unreachable it is discarded without its finalizer being invoked.
|
There are a few places within the java documentation, api and JLS, where
/required/ behavior is not /quite/ pinned down to my liking. Precisely
/what/ the GC is required to do on various platforms is one of them. I
consider it one of my bigger gripes.
....[rip]...
--
"Gentlemen, you can't fight in here! This is the War Room!"
|
|
| Back to top |
|
|
John C. Bollinger
Guest
|
| Posted: Wed Nov 10, 2004 4:08 pm Post subject: Re: Thread-question |
|
|
Thomas G. Marshall wrote:
| Quote: | John C. Bollinger coughed up:
I haven't looked up references (yet) but my understanding is that Carl
is correct, if perhaps overly emphatic. Based only on the API docs
and JLS, one can argue that instances of classes that do not override
finalize() can be collected without actually invoking
Object.finalize(), as the VM can know that its Object.finalize() is
specified to do nothing. More importantly, however, it is possible
for a finalize() method to make the object it is invoked on reachable
again (an odd state indeed: finalized and reachable), so after
finalizing an object with a non-default finalizer, the GC must
completely redo its reachability analysis for that object.
Naturally, that also affects the reachability of objects to which the
one in question holds references.
The VM must also keep track of whether or not reachable objects have
been finalized, because they are only ever finalized once (per
specification). That probably doesn't add much overhead, but it may
result in unexpected behavior when the second time an object becomes
unreachable it is discarded without its finalizer being invoked.
There are a few places within the java documentation, api and JLS, where
/required/ behavior is not /quite/ pinned down to my liking. Precisely
/what/ the GC is required to do on various platforms is one of them. I
consider it one of my bigger gripes.
|
There is a tension in most language and API specifications between
pinning down requirements very precisely so as to provide the least
ambiguous definitions, and describing requirements more generally so as
to allow more flexibility in implementation. Too far in either
direction doesn't make sense. Moreover, implementations typically
operate under an "as if" principle (any behavior is acceptable as long
as to any external observer it is indistinguishable from the specified
behavior).
In the case of GC, the API docs for Object.finalize() give a fairly
extensive discussion of the question, and JLS(2e) 12.6 covers the topic
in (IMO) reasonably complete detail, including an object lifecycle
diagram in 12.6.1. I believe everything I discussed (above) is in fact
described by the specification, even including the VM skipping
invocation of finalize() when it has not been overridden. I am
satisfied with the precision of the specification in that area; what
details would you prefer to see more completely specified?
John Bollinger
[email]jobollin (AT) indiana (DOT) edu[/email]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
