harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ilya Berezhniuk (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HARMONY-4766) [drlvm][thread] ThreadGroup.destroy() does not destroy groups with non-started threads
Date Mon, 10 Sep 2007 00:56:29 GMT

     [ https://issues.apache.org/jira/browse/HARMONY-4766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ilya Berezhniuk updated HARMONY-4766:
-------------------------------------

    Description: 
While investigating HARMONY-4361 I've discovered that ThreadGroup.destroy() behavior does
not match RI behavior.

I did not experiment with daemon groups, but for non-daemon groups ThreadGroup.destroy() throws
j.l.IllegalThreadStateException when trying to destroy thread group containing thread which
is not started yet.

API spec. says: "This thread group must be empty, indicating that all threads that had been
in this thread group have since stopped"
In other words, it should be possible to destroy group containing stopped thread, and also
containing subgroups with stopped threads.
Spec. says nothing about non-started threads... 

I've wrote simple test to check RI behavior, and on both Sun and BEA VMs it's OK to destroy
group with a thread which is not started yet.
Harmony throws exception for not started threads.

It's possible that some points in my test are incorrect, but it's evident that Harmony behavior
essentially differs from RI behavior.

  was:
While investigating HARMONY-4361 I've discovered that ThreadGroup.destroy() behavior is incorrect.

I did not experiment with daemon groups, but for non-daemon groups ThreadGroup.destroy() throws
j.l.IllegalThreadStateException when trying to destroy thread group containing thread(s),
regardless of conditions.

API spec. says: "This thread group must be empty, indicating that all threads that had been
in this thread group have since stopped"
In other words, it should be possible to destroy group containing stopped thread, and also
containing subgroups with stopped threads.

I've wrote simple test to check RI behavior, and on both Sun and BEA VMs it's OK to destroy
group with stopped thread, and even group with a thread which is not started yet.
Harmony throws exception for not started threads as well as for finished threads.

It's possible that some points in my test are incorrect, but it's evident that Harmony behavior
essentially differs from RI behavior.

        Summary: [drlvm][thread] ThreadGroup.destroy() does not destroy groups with non-started
threads  (was: [drlvm][thread] ThreadGroup.destroy() does not destroy groups with threads)

> [drlvm][thread] ThreadGroup.destroy() does not destroy groups with non-started threads
> --------------------------------------------------------------------------------------
>
>                 Key: HARMONY-4766
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4766
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>            Reporter: Ilya Berezhniuk
>         Attachments: TG1.java, TG1.java
>
>
> While investigating HARMONY-4361 I've discovered that ThreadGroup.destroy() behavior
does not match RI behavior.
> I did not experiment with daemon groups, but for non-daemon groups ThreadGroup.destroy()
throws j.l.IllegalThreadStateException when trying to destroy thread group containing thread
which is not started yet.
> API spec. says: "This thread group must be empty, indicating that all threads that had
been in this thread group have since stopped"
> In other words, it should be possible to destroy group containing stopped thread, and
also containing subgroups with stopped threads.
> Spec. says nothing about non-started threads... 
> I've wrote simple test to check RI behavior, and on both Sun and BEA VMs it's OK to destroy
group with a thread which is not started yet.
> Harmony throws exception for not started threads.
> It's possible that some points in my test are incorrect, but it's evident that Harmony
behavior essentially differs from RI behavior.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message