No subject

In such a system, there would be no "walkConservative".  That's why I
questioned that it should be added to the gc interface.

But, as you point out and I agree with you, the current state is clearly 
broken, so we might as well add it to the gc interface.

> 
>  But that whole strategy is worrisome anyway --- I'm not aware of
> anything in the Java language spec which keeps user-level code from
> doing their own waits and notifies on Thread (or subclassed Thread)
> objects, and that might interfere with Kaffe's use of those monitors
> to implement Thread.join().

Why would that interfere with Thread.join()?  The way Thread.join()
is implemented is:

	while (thread not done)
		wait on thread

This will work even in the presence of user-level code that notifies
and/or waits on that thread, will it not?
Sun's implementation does it the same way.

> 
> Hmmmm... I would have thought pthread_kill much more appropriate for
> implementing Thread.stop() than pthread_cancel.  (Thread.stop() is
> just supposed to cause a ThreadDeath exception to be thrown, but the
> target thread is allowed to catch the exception, spend an arbitrary
> amount of time dealing with it, and even discard it.  The whole effect
> is very much like sending SIGQUIT to a Unix process.  Does
> pthread_cancel give the target thread a chance to process the event?)

I do not rule out that pthread_kill could be used.

However, from reading the rationale in the PTHREAD document,
pthread_cancel is the function that was designed for that.  The writers
of the standard draft frequently refer to how language run-time systems 
would use pthread_cancel to implement thread stopping.  I think they
had ADA in mind at the time.

Cleanup, in Java's case throwing ThreadDeath, is done in a cleanup
handler that can be specified using pthread_cleanup_push().
I think you can longjmp out of such a handler, which is what
catching that exception would mean. 

As for the question whether the target thread is allowed to catch
that exception *and* to continue, I'm not going to touch it.  The
language spec says that a thread should rethrow it, but as far as I
can tell, Sun's verifier doesn't enforce it.  Funny enough,
Thread.currentThread().isAlive() returns false within your own
ThreadDeath handler (see also the test cases we added for jthread
Kaffe, CatchDeath.java)  Add to that that Thread.stop is deprecated
in JDK 1.2.


To add to the destroying locks issue, I talked to Pat about it, and
he's done some measurements that seem to indicate that the lack of lock 
gc does not seem to be a problem in practice.  But it is certainly 
necessary to guard against pathological cases.


Also, thanks for your comments about NSPR.

	- Godmar