JDK-4162694 : (thread) ThreadGroup.activeCount() doesn't always reach 0 after stop() called
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.2.0
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 1998-08-02
  • Updated: 2007-03-12
  • Resolved: 2007-03-12
Related Reports
Relates :  
JDK-4159054 - sun.awt.AppContext needs a dispose()
Relates :  
JDK-4189292 - (thread spec) ThreadGroup and Thread need better and tighter specs
Relates :  
JDK-4082405 - (thread) Thread.enumerate() yields wrong result (it counts inactive threads)
Description
I recently wrote sun.awt.AppContext.dispose() which, among other things, calls
ThreadGroup.stop() and waits for ThreadGroup.activeCount() to return 0 before
calling ThreadGroup.destroy().

The problem is that ThreadGroup.activeCount() never goes down to 0 when
appletviewer calls my sun.awt.AppContext.dispose() method.  activeCount()
returns 1, but ThreadGroup.enumerate() returns 0, so I can't even determine
the offending Thread.

In ThreadGroup.java, activeCount() returns nthreads, but enumerate() counts
only those Threads for which isAlive() returns true.  Shouldn't these work
the same?
Comments
EVALUATION The eval of 4162893 explains the mechanism preventing one of the threads from reaching Thread.exit (and thus being removed from its group), so the root cause is understood. And the complaint about enumerate vs activeCount is covered by other change requests and doesn' need separate coverage here.
12-03-2007
EVALUATION This bug isn't about activeCount, per se, it's about something interfering with one of the threads being removed from its group as part of its stoppage. Considering the relative hazard level of ThreadGroup.stop this behavior shouldn't be too surprising, but it would be worthwhile understanding it and correcting it if that's practical for the sake of strengthening the emerging spec for "active" threads in thread groups.
20-09-2005