[cp-patches] FYI: Addition of threading bean

Andrew John Hughes a.hughes at dcs.shef.ac.uk
Tue Jun 27 07:14:02 UTC 2006


Hi Tom,

On 26 Jun 2006, at 22:29, Tom Tromey wrote:

>>>>>> "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 :)
>

I agree; unfortunately, we need it on both branches in some form to  
keep the
VM layer in sync.

> 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.
>

I would have preferred to go with an int, but there seems to be no  
method in
the Enum class to convert ints back into enums, while there is one  
for Strings.
String is also the form used by the open MBean interface, so the  
dynamic lookup
info for the beans (when implemented) will emit the enum as a String  
too.
> 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.
>
Yeah, I wasn't too sure how you'd implemented this; is there already  
some
way of passing in an id and getting the corresponding thread?  That's  
how
these ThreadInfo instances are created.
> Tom

Cheers,
--
Andrew :)

Postgraduate Student
Verification and Testing Group
Department of Computer Science
University of Sheffield


>



More information about the Classpath-patches mailing list