Compiling kaffe under windows NT4 with cygwin.
Title: Compiling kaffe under windows NT4 with cygwin. Hi all, I want to compile kaffe but I've a pb : when I call make, there is an error : In the file cygus\usr\i686-pc-cygwin\include\windef.h - line 177, there is : typedef HKEY *PHKEY; But the HKEY type is defined nowhere (and some files as winreg.h, ... use this type) Is anyone that know this type ??? Gilles.
Re: Thread.stop()
Jason Baker writes: I noticed some inconsistency in Thread.stop(Throwable). When an interruptable thread is stopped, the we get the calling thread's stacktrace. When a thread is asynchronously killed, we get the dying thread's stacktrace, but not in the exception stop was passed in. I think we should always get the dying thread's stacktrace. (Does anyone know what the JDK does?) Email me a simple test case and I'll run it under both kaffe and JDK 1.2. -AC ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Re: Thread.stop()
Archie Cobbs [EMAIL PROTECTED] writes:
Email me a simple test case and I'll run it under both kaffe and JDK 1.2.
Weird. Blackdown 1.2.2 doesn't seem to asynchronously stop threads at
all, while jdk 1.1.7 can do it some of the time. Neither one seems to
throw an exception with a stack trace at all.
Jason
--
1.2.2:
nephi(53) java Die
sleeper started
doing it...
loop started
caught an error
java.lang.Error: throwing from main
done
doing it...
^C
--
1.1.7:
nephi(57) java Die
sleeper started
doing it...
loop started
caught an error
java.lang.Error: throwing from main
done
doing it...
^C
nephi(59) java Die 100
sleeper started
doing it...
loop started
caught an error
java.lang.Error: throwing from main
done
doing it...
caught an error
java.lang.Error: throwing from main
done
--
patched kaffe:
sleeper starteddoing it...
loop started
caught an error
java.lang.Error: throwing from main
at java.lang.Thread.waitOn(Thread.java:475)
at java.lang.Thread.sleep(Thread.java:364)
at Die$1.doIt(Die.java:24)
at Die.run(Die.java:7)
done
doing it...
caught an error
java.lang.Error: throwing from main
at Die.run(Die.java:7)
done
--
public abstract class Die extends Thread {
abstract void doIt();
public void run()
{
System.err.println("doing it...");
try { doIt(); }
catch (Error e) {
System.err.println("caught an error");
e.printStackTrace(System.err);
}
System.err.println("done");
}
static public void main(String[] args)
throws InterruptedException
{
int startup = 1000;
if (args.length 0)
startup = Integer.parseInt(args[0]);
Thread u = new Die() {
void doIt() {
try { Thread.sleep(30); }
catch (InterruptedException _) { }
}
};
u.start();
System.err.println("sleeper started");
Thread.sleep(startup);
u.stop(new Error("throwing from main"));
Thread t = new Die() {
void doIt() { while (true) ; }
};
t.start();
System.err.println("loop started");
Thread.sleep(startup);
t.stop(new Error("throwing from main"));
}
}
Re: Thread.stop()
I was under the impression that methods like Thread.stop() were
removed from the JDK or replaced with no-ops. I seem to remember
that they were never implemented in Netscape's JVM. The whole
concept of stoping a thread seems like a bad idea, a thread
should expire due to natural causes.
Here are some notes about it from the Sun developer site.
http://developer.java.sun.com/developer/bugParade/bugs/4187649.html
http://developer.java.sun.com/developer/bugParade/bugs/4248898.html
Mo Dejong
Red Hat Inc.
On 22 May 2000, Jason Baker wrote:
Archie Cobbs [EMAIL PROTECTED] writes:
Email me a simple test case and I'll run it under both kaffe and JDK 1.2.
Weird. Blackdown 1.2.2 doesn't seem to asynchronously stop threads at
all, while jdk 1.1.7 can do it some of the time. Neither one seems to
throw an exception with a stack trace at all.
Jason
--
1.2.2:
nephi(53) java Die
sleeper started
doing it...
loop started
caught an error
java.lang.Error: throwing from main
done
doing it...
^C
--
1.1.7:
nephi(57) java Die
sleeper started
doing it...
loop started
caught an error
java.lang.Error: throwing from main
done
doing it...
^C
nephi(59) java Die 100
sleeper started
doing it...
loop started
caught an error
java.lang.Error: throwing from main
done
doing it...
caught an error
java.lang.Error: throwing from main
done
--
patched kaffe:
sleeper starteddoing it...
loop started
caught an error
java.lang.Error: throwing from main
at java.lang.Thread.waitOn(Thread.java:475)
at java.lang.Thread.sleep(Thread.java:364)
at Die$1.doIt(Die.java:24)
at Die.run(Die.java:7)
done
doing it...
caught an error
java.lang.Error: throwing from main
at Die.run(Die.java:7)
done
--
public abstract class Die extends Thread {
abstract void doIt();
public void run()
{
System.err.println("doing it...");
try { doIt(); }
catch (Error e) {
System.err.println("caught an error");
e.printStackTrace(System.err);
}
System.err.println("done");
}
static public void main(String[] args)
throws InterruptedException
{
int startup = 1000;
if (args.length 0)
startup = Integer.parseInt(args[0]);
Thread u = new Die() {
void doIt() {
try { Thread.sleep(30); }
catch (InterruptedException _) { }
}
};
u.start();
System.err.println("sleeper started");
Thread.sleep(startup);
u.stop(new Error("throwing from main"));
Thread t = new Die() {
void doIt() { while (true) ; }
};
t.start();
System.err.println("loop started");
Thread.sleep(startup);
t.stop(new Error("throwing from main"));
}
}
Re: Thread.stop()
I also found this note in kaffe/FAQ/FAQ.pthreads
* We do not support asynchronous exceptions via Thread.stop()
Mo Dejong
Red Hat Inc.
On Mon, 22 May 2000, Mo DeJong wrote:
I was under the impression that methods like Thread.stop() were
removed from the JDK or replaced with no-ops. I seem to remember
that they were never implemented in Netscape's JVM. The whole
concept of stoping a thread seems like a bad idea, a thread
should expire due to natural causes.
Here are some notes about it from the Sun developer site.
http://developer.java.sun.com/developer/bugParade/bugs/4187649.html
http://developer.java.sun.com/developer/bugParade/bugs/4248898.html
Mo Dejong
Red Hat Inc.
On 22 May 2000, Jason Baker wrote:
Archie Cobbs [EMAIL PROTECTED] writes:
Email me a simple test case and I'll run it under both kaffe and JDK 1.2.
Weird. Blackdown 1.2.2 doesn't seem to asynchronously stop threads at
all, while jdk 1.1.7 can do it some of the time. Neither one seems to
throw an exception with a stack trace at all.
Jason
--
1.2.2:
nephi(53) java Die
sleeper started
doing it...
loop started
caught an error
java.lang.Error: throwing from main
done
doing it...
^C
--
1.1.7:
nephi(57) java Die
sleeper started
doing it...
loop started
caught an error
java.lang.Error: throwing from main
done
doing it...
^C
nephi(59) java Die 100
sleeper started
doing it...
loop started
caught an error
java.lang.Error: throwing from main
done
doing it...
caught an error
java.lang.Error: throwing from main
done
--
patched kaffe:
sleeper starteddoing it...
loop started
caught an error
java.lang.Error: throwing from main
at java.lang.Thread.waitOn(Thread.java:475)
at java.lang.Thread.sleep(Thread.java:364)
at Die$1.doIt(Die.java:24)
at Die.run(Die.java:7)
done
doing it...
caught an error
java.lang.Error: throwing from main
at Die.run(Die.java:7)
done
--
public abstract class Die extends Thread {
abstract void doIt();
public void run()
{
System.err.println("doing it...");
try { doIt(); }
catch (Error e) {
System.err.println("caught an error");
e.printStackTrace(System.err);
}
System.err.println("done");
}
static public void main(String[] args)
throws InterruptedException
{
int startup = 1000;
if (args.length 0)
startup = Integer.parseInt(args[0]);
Thread u = new Die() {
void doIt() {
try { Thread.sleep(30); }
catch (InterruptedException _) { }
}
};
u.start();
System.err.println("sleeper started");
Thread.sleep(startup);
u.stop(new Error("throwing from main"));
Thread t = new Die() {
void doIt() { while (true) ; }
};
t.start();
System.err.println("loop started");
Thread.sleep(startup);
t.stop(new Error("throwing from main"));
}
}
Re: Thread.stop()
Jason Baker wrote: Thread.stop is dangerous, but without a process model there is really no alternative. I'm using it to halt infinite loops, which is why I need the stack trace. I'm pretty sure that the official position from Sun is that there is no way to stop uncooperative threads in a JVM. According to Sun, you just restart the whole JVM. Both Godmar and Pat use Thread.stop to implement safe termination, so given that it is part of Kaffe, what should the call do? I don't exactly use Thread.stop() in Janos or Alta. I make sure the target thread is stopped in a clean spot (not in the kernel, or other system code) and then just clean it up with a direct jthread_ call. (Technically, this is just what is *supposed* to happen, neither system completely implements termination of very uncooperative threads.) Godmar's solution is quite similar, I think. The real problem with Thread.stop() is that it can stop threads when they're in places like the GC or in the JAR code, and can leave the VM in an unstable state. If you really need to terminate uncooperative Threads, you're going to have to make sure they're not executing critical JVM code. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] This space unintentionally left blank.
Re: Ksem lifetime?
Here's another detail that I've been puzzling over while debugging the beos-native Ksem implementation: when is a Ksem that isn't explicitly destroyed actually destroyed? Is a Ksem's lifetime co-terminal with its "owner", or does it continue existing until explicitly destroyed? Ksems are allocated one per thread, and should live only as long as the thread they're associated with. (Look for ksem in kaffe/kaffevm/threads.c.) I think you know this though, so I wonder if I'm missing the point... There are iLock objects that are dynamically allocated, but the threading system never sees those. I've been assuming all along that each jthread destroys all of the locks that it created itself, prior to invoking jthread_exit. Threads (generally) should not exit while holding locks. While this isn't entirely true (see the concurrent Thread.destory() topic), it shouldn't be the responsibility of the threading layer to clean this up. (We need to fix the VM layer to protect itself.) Is this assumption correct, or should I add code to my threading layer that destroys each of a native thread's semaphores immediately before the thread itself exits? You shouldn't have to do this, as the VM-level threading api cleans up its per-thread Ksems as its threads are destroyed. I only just noticed an interesting side-effect of the way Kaffe uses Ksems is that the "owner" thread is the only thread in the system that will block on its Ksem. Also, the "owner" should never signal on its own Ksem, only the Ksems of other threads. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] "You can't have everything. Where would you put it?" -- S. Wright
Re: Thread.stop()
Jason Baker [EMAIL PROTECTED] writes: Archie Cobbs [EMAIL PROTECTED] writes: Email me a simple test case and I'll run it under both kaffe and JDK 1.2. Weird. Blackdown 1.2.2 doesn't seem to asynchronously stop threads at all, while jdk 1.1.7 can do it some of the time. Neither one seems to throw an exception with a stack trace at all. Some of you where probably wondering what I found weird: I'm not surprised that 1.2.2 doesn't handle asynchronous stops. I am surprised that synchronously delivered stop exceptions don't carry any stack trace. I'm also completely at a loss to explain when stop works in 1.1.7. Does anyone think that Thread.waitOn should emulate jdk behavior and clear out the stack trace from a Thread.stop() exception before throwing it? Jason -- 1.2.2: nephi(53) java Die sleeper started doing it... loop started caught an error java.lang.Error: throwing from main done doing it... ^C -- 1.1.7: nephi(57) java Die wait 1 second before calling Thread.stop() sleeper started doing it... loop started caught an error java.lang.Error: throwing from main done doing it... ^C nephi(59) java Die 100 wait 0.1 seconds, but 0.8 works too. sleeper started doing it... loop started caught an error java.lang.Error: throwing from main done doing it... caught an error java.lang.Error: throwing from main done -- patched kaffe: sleeper starteddoing it... loop started caught an error java.lang.Error: throwing from main at java.lang.Thread.waitOn(Thread.java:475) at java.lang.Thread.sleep(Thread.java:364) at Die$1.doIt(Die.java:24) at Die.run(Die.java:7) done doing it... caught an error java.lang.Error: throwing from main at Die.run(Die.java:7) done
Re: Thread.stop()
On Mon, 22 May 2000, Jason Baker wrote:
Mo DeJong [EMAIL PROTECTED] writes:
I was under the impression that methods like Thread.stop() were
removed from the JDK or replaced with no-ops. I seem to remember
that they were never implemented in Netscape's JVM. The whole
concept of stoping a thread seems like a bad idea, a thread
should expire due to natural causes.
There is (or was, I have the docs for a JDK 1.3 beta) a nice document
explaining the various issues on thread stopping linked from the
method summary of java.lang.Thread. It is called "Why Are Thread.stop,
Thread.suspend, Thread.resume and Runtime.runFinalizersOnExit Deprecated?", and
should be the file jdk1.3/docs/guide/misc/threadPrimitiveDeprecation.html in
the JDK 1.3 documentation. Essentially, it makes the point, that unless you
really, really know what you're doing, Thread.stop() leaves your objects in a
damaged state, and leads to unleasant surprises.
Thread.stop(Throwable) is even worse: in addition anyone can pass any exception
to your thread, even exceptions it's not prepared to catch ...
There is an implementation of Thread.stop and other deprecated Thread methods
in the JDKs, it's just marked deprecated since JDK 1.2.
In Peter Haggar's "Practical Java" he talks about thread stopping in praxes 57
58, and essentially recommends the same things Sun does: don't use
Thread.stop(). If you have to do stop threads, use polling on a volatile
variable (since threads can copy local variables), or use synchronized methods
to access it. If the stop variable is true, then clean up your resources, put
the object in a safe state, and exit via the Thread.run method(). The
disadvantage is: the thread does not stop immediately, it has to read the stop
variable first.
If that's an issue, like for threads that wait for a long period, than you
should additionally use interrupts. There are examples of all that in Sun's
document described above.
Thread.stop is dangerous, but without a process model there is really
no alternative. I'm using it to halt infinite loops, which is why I
need the stack trace.
I'd say, try to use polling. Something like this should do it:
class InfiniteLoopThread extends Thread {
private volatile boolean quit;
public void stop() {
quit = true;
}
public void safeStop(Throwable t) {
quit = true;
// if you need the stack trace
// to see who stopped the thread
t.printStackTrace();
}
public void run() {
while (!quit) {
// your infinitely looping code
}
// oops! turned out to be finitely looping!
// do the clean up.
// dump the stack trace
// if you still need it
this.dumpStack();
}
}
Both Godmar and Pat use Thread.stop to implement safe termination, so
given that it is part of Kaffe, what should the call do?
According to the JDK 1.3 API documentation the Thread.stop() method should look
something like this:
public void stop() {
SecurityManager sm;
sm = System.getSecurityManager())
if(sm) {
sm.checkAccess(this);
if(this != currentThread()) {
sm.checkPermission(new RuntimePermission("stopThread"));
}
}
throw (new ThreadDeath());
}
Thread.stop(Throwable) should be very similar.
There is one thing that the JDK 1.3 documentation says about printing stack
traces:
The top-level error handler that reacts to otherwise uncaught exceptions does
not print out a message or otherwise notify the application if the uncaught
exception is an instance of ThreadDeath.
I think your 'Die' code shows a bug or two in the JDK 1.2.2 and JDK 1.1.7. It
should generate stack traces since you're throwing Errors around, not
ThreadDeaths. Unless of course, Sun's JVM generally doesn't print stack traces
on Errors or Throwables, but I haven't found anything supporting that in the
documentation for java.lang.Error or java.lang.Throwable.
Last time I looked at Kaffe's threads, it didn't do
the SecurityManager checks, so Kaffe is not 'fully compliant' with JDK 1.3
specification (or 1.2, for that matter) either.
hope this helps,
Dali
__
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Re: garbage collecting interfaces
Timothy Stack writes: There seems to be a bug in the destroyClass function when trying to garbage collect an interface. It attempts to get the native code for a method, but ends up just dereferencing a null pointer. The following code extends the ClassGC test to include a class that implements a dummy interface and a simple fix for destroyClass. Unfortunately, I don't know how to verify that the interface was actually collected, but atleast it doesn't crash anymore. Good catch.. thanks, I checked in your patches. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
