> From: Washburn, Weldon [mailto:[EMAIL PROTECTED]]
>
> I have been working with a snapshot dated 8/4/00 and have hit
> three bugs in
> java.lang.Thread. If the following mods have already been made, please
> ignore this email.
>
Thanks! These mods had not been made yet. Look at my checkin and see if it
does everything you need. I changed a few things around and made one of
them a little closer to the spec, you might wish to apply the diff to your
version of Classpath.
> java.lang.Thread.<init>(ThreadGroup group, Runnable toRun, String
> name) does
> not appear to
> set a useful default value for the name field. The following
> diff sets it:
>
> <
> 203c203,208
> < this.name = name;
> ---
> > if ( this.name == null )
> > {
> > String ss = "Thread-" + (++numThreadsCreated);
> > this.name = ss;
> > }
>
I am not sure if this is necessary, since otherwise there is no way to
initialize the name to null, but I can see the rationale--many other classes
use the motif of "null means set to default value". Fixing.
> Also, public final void join(long ms, int ns) appears to have reversed the
> sense of the isAlive() test. This results in race conditions when
> multithreaded apps try to synch via a join() statement. Diffs
> for this are
> included below:
>
> 360c365,366
> < while(!isAlive())
> ---
> > while(isAlive())
> 364c370,371
> < if(isAlive())
> ---
> > if(!isAlive())
>
>
Ick. This looks right. Good catch.
> The method called public String toString() returns null which results in a
> println(thr_obj) that prints nothing. The below diff sets it to the name
> field instead:
>
> 514c521
> < return "";
> ---
> > return this.name;
>
Looking through the JLS
(http://java.sun.com/docs/books/jls/html/javalang.doc18.html#2680) it states
a more elaborate toString. I have put it in.
> Finally, the current java.lang.Thread does not appear to make it easy to
> associate an internal VM thread block with a java Thread object.
> This could
> be easily solved by adding the following field to the beginning of the
> class. For example:
>
> public class Thread {
> private Object data;
> ...
> ...
> ...
>
As for this one, that is why Thread is in vm/reference. That is the Japhar
implementation of Classpath. All classes in vm/reference are meant for you
to modify (in fact, the theory is if you make them work then all Classpath
will work). In Japhar, you have the opportunity to associate a native
pointer directly with an object, obviating the need for the Object field.
You should probably create a different directory under vm for your code, and
copy the stuff you've done into there. You can see the Kaffe code in
configure.in to find out how to make configure work.
--John Keiser
