Java Threads mailing list archive

Re: Thread.stop, suspend and resume deprecation in 1.2

Rick Beton wrote:

> > Ah ... I've just remembered that we don't actually use Thread.suspend at
> > all ... we use ThreadGroup.suspend etc.  Have these ThreadGroup methods
> > been deprecated in 1.2?
> 
> Yes they have.
> 
> (see http://java.sun.com/products/jdk/1.2/docs/api/index.html)

Thanks!  I went and looked to see their reason.  They refer back to the
Thread.suspend method.  Referring back tells you that it's been deprecated
because `it is inherently deadlock-prone' and they go on to explain a very
silly way of using it that quickly leads to deadlock.

But we don't use it that way.  We only have *one* thread that does the
suspending and the resuming and is not otherwise involved in the threads
it is controlling.  In the case of the Threadgroup methods, that thread
stands outside the threadgroup on which it is operating and suspends
and resumes the threadgroup perfectly safely -- the scenario painted
in the deprecation documentation does not arise.

So how is a JDK 1.2 applet supposed to suspend and resume a bunch of
threads contained in the applet?  Actually, the applet terms are `start'
and `stop' and they get called whenever you move (respectively) on and off
the page containing the applet.  If the applet contains lots of threads
(or, in the case of our ActiveApplet, one ThreadGroup), how are we supposed
to stop and start them -- ThreadGroup.suspend and resume did exactly that!

Or ... are they advising us anywhere not to use multiple threads in applets
... as they (sort of) did for Swing GUIs ... :-)

Help please,

Peter.