On 05/07/2013 09:51 AM, Thomas Schatzl wrote:
Hi all,

On Tue, 2013-05-07 at 12:31 +1000, David Holmes wrote:
Catching ThreadDeath is futile. If someone is invoking stop() then you
can encounter the ThreadDeath anywhere and it is impossible to write
completely robust code in the face of such an async exception. So please
let's not even go there. stop() is long deprecated and should never be used.

Backing up I think the try/catch(IE|OOME) around wait() is the most
reasonable solution here. Anyone messing with instrumentation or
overriding etc can break things - so be it - don't do that.
StackOverflowError can also completely break many things - again it is
effectively an async exception and writing async-exception-safe Java
code is impractical if not impossible.
   I can understand this reasoning.

I provided a new patch (this time for review)
http://cr.openjdk.java.net/~tschatzl/7038914/webrev.1/ which implements
this change as suggested.

Regarding regression testing, I marked this bug as "noreg-other" with
the explanation that it is too hard to write a proper regression test,
and the note that any test would involve using methods that we don't
give any guarantees for (overriding package private jdk methods,
instrumentation).

Hi Thomas,

Does the bug reproducer I sent to the list not work for you? The test can check the return value of refQueue.poll() and decide if it passes or not (null return means the ReferenceHandler thread has died and the bug is here, non-null return means thread still works and there is no bug).

Regards, Peter


I need reviewers and a sponsor pushing this as I don't have any role in
the jdk project, and this is a jdk only patch.

Thanks,
Thomas



Reply via email to