#!/bin/ksh
#JAVA_HOME=/net/jde1.eng/export/jtech26/ysr/exactjava/build/solaris
JAVA_HOME=/net/mulder.eng/export/mulder3/jdk12x/sparc/jdk1.2FCS_R
JCK=/net/ultrajaguar.eng/export/testbase/src/JCK-12a
if [ ! -f  setDaemon0101.java ]; then
  cp ${JCK}/api/java_lang/ThreadGroup/setDaemon01/setDaemon0101/setDaemon0101.java .
fi
if [ ! -f  setDaemon0101.html ]; then
  cp ${JCK}/api/java_lang/ThreadGroup/setDaemon01/setDaemon0101/setDaemon0101.html .
fi
if [ ! -f  setDaemon0101.cfg ]; then
  cp ${JCK}/api/java_lang/ThreadGroup/setDaemon01/setDaemon0101/setDaemon0101.cfg .
fi
export PATH=${JAVA_HOME}/bin:/usr/bin:/bin
export CLASSPATH=${JCK}/classes:${JCK}/javatest.jar
export THREADS_FLAG=native
STATUS=95
while [ ${STATUS} = "95" ]; do
java  -Xverify:none   javasoft.sqe.tests.api.java.lang.ThreadGroup.setDaemon0101.setDaemon0101
STATUS=$?
done
B
Start a lot of copies of the above script going in separate windows of
a sparc workstation (say 7).  Then wait.  Eventually:

STATUS:Passed.
STATUS:Passed.
STATUS:Passed.
STATUS:Passed.
STATUS:Passed.
STATUS:Passed.
STATUS:Passed.
STATUS:Passed.
STATUS:Passed.
STATUS:Passed.
STATUS:Failed. daemon group not destroyed
algol% 

The reason that multiple copies are required is that paging is being used to
disrupt the timing of ThreadGroup destruction.

For more information see the bug filed against this (in my opinion bogus) test:
Bug ID 4188006.

I'll try to get around to filing an RFE against the specification asking for
more precision about questions of Thread and ThreadGroup destruction.  There are
multiple method calls with indeterminate results.

allan.jacobs@Eng 1998-11-20