[cp-patches] FYI: Addition of threading bean

Tom Tromey tromey at redhat.com
Mon Jun 26 21:29:40 UTC 2006

>>>>> "Andrew" == Andrew John Hughes <gnu_andrew at member.fsf.org> writes:

Andrew> Most of this depends on the state of the thread, which it appears
Andrew> we don't as yet have.  This patch thus also includes the addition
Andrew> of a new native method to the VMThread interface to obtain the state.
Andrew> Due to this being an enumeration in 1.5, we simply use a String here
Andrew> and take the JAPI warnings on the chest.

This is mildly irritating, but at least it is temporary :)

Andrew> The VM layer one is likely to
Andrew> remain a String anyway, as it is simpler to pass around in native
Andrew> code (I presume; correct me if I'm wrong).

For gcj, at least, using an enum constant is just as easy.  Perhaps
easier, actually.

My plan here has been to add a new C++ class to set the thread state,
and which resets the state in its destructor, and then insert
instances of this class everywhere we need to record a state change in
the native code.

The Classpath native code will need a similar, but uglier and more
error-prone :(, treatment.

Alternatively we could use an int on the VM side and map our constants
back to enum constants in Thread.getState.  ints have the nice quality
that they are easy from both CNI and JNI.

Andrew> I'll take a look at this further when I implement the bean,
Andrew> but it seems even non-Java-created threads will need an id.

The VM ought to handle this -- when a user thread registers via JNI, a
Thread object (and thus an id) ought to be created.


More information about the Classpath-patches mailing list