Hi Jeroen,
On 29 Jun 2006, at 09:33, Jeroen Frijters wrote:
Andrew John Hughes wrote:
This patch puts a bit more into thread state handling.
I apologize for being blunt, but this patch is unacceptable. It
doesn't
cover all cases, it's incorrect and inefficient.
Yes, I acknowledged this in my comments on the patch. You can't cover
all state changes in the Thread code, so it won't cover all cases.
Based on your comments, it seems you agree with my original intuition
of making this a native VM call (by default) in the majority of
cases, but
efficiency would seem to be fairly VM specific.
I suppose I was aiming on lightening the load on the VM interface, as
I seem to be throwing tons down there lately. I'd be interested in
comments
from other VM coders as to what they feel is best.
I'll revert to something similar this evening, but the real test will
be when I add
some of this to gcj.
I really think it's best to leave determining the thread state up to
VMThread, except of course that there still needs to be support for
threads that don't yet (or no longer) have a VMThread.
Below is a patch that shows what I think getState should look like.
Regards,
Jeroen
Index: java/lang/Thread.java
===================================================================
RCS file: /cvsroot/classpath/classpath/java/lang/Thread.java,v
retrieving revision 1.26
diff -u -r1.26 Thread.java
--- java/lang/Thread.java 27 Jun 2006 21:57:29 -0000 1.26
+++ java/lang/Thread.java 29 Jun 2006 08:30:11 -0000
@@ -1239,7 +1239,11 @@
public String getState()
{
VMThread t = vmThread;
- return t == null ? null : t.getState();
+ if (t != null)
+ return t.getState();
+ if (group == null)
+ return "TERMINATED";
+ return "NEW";
}
/**
