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.
I really think it's best to leave determining the thread state up to
VMThread, except of
Andrew John Hughes wrote:
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.
Sure, but Thread.getState() is unlikely to be used very often and should
On 29 Jun 2006, at 11:04, Jeroen Frijters wrote:
Andrew John Hughes wrote:
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.
Sure, but
On Thu, 2006-06-29 at 10:35 +0100, Andrew John Hughes wrote:
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
On Wed, 2006-06-28 at 21:07 +0100, Andrew John Hughes wrote:
This patch puts a bit more into thread state handling.
It adds a variable to hold the state inside the thread
(in much the same way as the name is handled). It also
updates some of the methods so that they also update the
state. A
On Thu, 2006-06-29 at 10:33 +0200, 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.
I really think it's best to
