l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
April 21: Google Glass
Next Installfest:
TBD
Latest News:
Mar. 18: Google Glass at LUGOD's April meeting
Page last updated:
2003 Apr 22 09:00

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Java Threads: Abort not found...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Java Threads: Abort not found...



--On Friday, April 18, 2003 06:44:45 PM -0400 Mike Simons <msimons@moria.simons-clan.com> wrote:

On Fri, Apr 18, 2003 at 02:32:15PM -0700, Ken Herron wrote:

  I'm irritated about Java preventing one thread of forcefully stopping
another thread... If you start a child thread that makes a blocking call
into something, there doesn't appear to be a way for the parent thread
to decide the child has taken too long and forcefully abort the child
thread, or even get it to return from that blocked call.
I remember seeing some discussions about thread cancellation back when java was brand new. From what I understood of the situation, java's original thread API included thread cancellation, but it was quickly deprecated because the functionality was poorly specified, and in general it's extremely difficult to do thread cancellation properly.

Looking at the java 1.4.1 platform API spec, the thread class includes stop(), suspend(), and resume() methods, but they're all marked deprecated. They include a page explaining why they're deprecated, for example:

Why is Thread.stop deprecated?

Because it is inherently unsafe. Stopping a thread causes it to unlock
all the monitors that it has locked. (The monitors are unlocked as the
ThreadDeath exception propagates up the stack.) If any of the objects
previously protected by these monitors were in an inconsistent state,
other threads may now view these objects in an inconsistent state. Such
objects are said to be damaged. When threads operate on damaged
objects, arbitrary behavior can result. This behavior may be subtle and
difficult to detect, or it may be pronounced. Unlike other unchecked
exceptions, ThreadDeath kills threads silently; thus, the user has no
warning that his program may be corrupted. The corruption can manifest
itself at any time after the actual damage occurs, even hours or days
in the future.
I think there's a consensus that forcibly making a thread disappear is a "hard" problem, because cleaning up the thread's resources can be extremely complex. The issue isn't specific to java; it applies to threads in the abstract and can even be seen with processes. The only practical method is to notify the thread to shut itself down and hope it pays attention. Toward that end java has an interrupt() method you can use to tell a thread to shut down.

--
Ken Herron
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.