harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ilya Berezhniuk" <ilya.berezhn...@gmail.com>
Subject ThreadGroup.destroy() behavior
Date Tue, 11 Sep 2007 18:45:45 GMT
Hi all.

I have some difficulties with understanding API spec. and RI behavior
regarding ThreadGroup.destroy(). Harmony behavior does not meet RI
behavior, and looks like RI behavior does not stick to spec.

Recently I investigated HARMONY-4361 and have found that this test is
incorrect. I've fixed it partially and have observed strange
ThreadGroup.destroy() behavior. This behavior differs from RI, so I've
filed HARMONY-4766.
But now I don't know what to do with both these bugs: looks like they
relate to compatibility (at least in one of suspicious points
Harmony's implementation is closer to API spec).

The API spec says "Destroys this thread group and all of its
subgroups. This thread group must be empty, indicating that all
threads that had been in this thread group have since stopped."
The problems are the following:

1) When some thread was added to thread group and not being started
yet, Harmony throws an exception on ThreadGroup.destroy() attempt for
such group, while RI destroys such group successfully.

I think RI behavior is reasonable, because non-started thread can be
considered as stopped.

Moreover, an attempt to start a thread belonging to destroyed group on
RI leads to exception in ThreadGroup.add(). It looks like RI actually
adds a thread to its group only when thread is started. The possible
reason is to allow garbage collection of non-started threads (see

2) When some group contains empty subgroup, both RI and Harmony can destroy it.

When subgroup contains terminated thread, Harmony destroys parent
group successfully, while RI throws an exception. Subgroup itself can
be destroyed on RI; but RI still throws an exception when trying to
destroy parent group with such destroyed subgroup.

This issue is described in RI bug report [2], but this bug is closed
as duplicate and duplicated bug itself 'is not available'. Seems like
Harmony behavior is closer to spec. in this case.

I want to fix the test from HARMONY-4361 to check correct behavior,
and fix ThreadGroup.destroy() if needed.
But I should know what behavior we should expect from Harmony...

[1] http://bugs.sun.com/view_bug.do?bug_id=4902813
[2] http://bugs.sun.com/view_bug.do?bug_id=4835100
[3] http://bugs.sun.com/view_bug.do?bug_id=6569710


View raw message