Tying up loose threads
I was reading the book "Java After Hours", and came across this warning
about threads:
<quote>
On some systems, threads are launched as their own processes, and
sometimes, they can get away from you if you're not careful.
[Story about forking off processes over a weekend omitted.]
... be carefuk about what you do with threads and not ending spawed processes.
</quote>
In the accompanying code, he makes a point of ending an animation thread
when the application is terminating.
This seems confused to me. Threads and processes are different things
and he's confusing them. I have never heard anyone else claim "On some
systems, threads are launched as their own processes" -- is that true?
Should one write code to terminate threads when an application is exiting?
Why bother?
Thats interesting if its true (about unmanaged processes spawning
off). Id think at the very least the JVM would corral all those things
and close them by the time it exits.
Is that a guy or girl on the cover, lol?!
What is the "Typing Across the Internet: The Intercom" project?
>
> Should one write code to terminate threads when an
> application is exiting?
Hmmmm.
> Why bother?
My first impression is that that book is rubbish. But for what it's worth I think there are two comments I would offer.
Once upon a time there were VMs (on Linux IIRC) that used green threads and not real threads. Green threads are VM emulated. This doesn't have anything to do with processes really except that for example now on Linux systems when you have seperate threads Linux sees them as disparte processes. This results in erroneous information for example Tomcat might be reported to have 20 processes consuming 400 MB of memory when in fact it is 10 threads that consume 20 MB but Linux counts each one seperatley.
Like i said not overly relevent, but a possible source of some confusion.
As far as the second point on terminating threads on application termination goes. I suppose it depends on how one defines termination. If you call System.exit then the VM and all running threads exit. If for example you just define termination as the end of the main method... well then yes the VM could keep running and will keep running as long as one or more non-daemon threads are running.
Is that what the author means?
The other possibility is something to do with Runtime.exec which leads to a whole other area of gloop. But I get the sense that isn't what was intended.
All in all I think the book is rubbish. The alternative is that you did a poor job of interpreting it and between those two options I lean towards the former over the latter. There may be some legit points, sort of, in a way, but that's as poor an explanation as one could give I think.
