Re: trouble building libgcj on FreeBSD 2.2.7

[Godmar Back <gback@cs.utah.edu>]

 I believe that using pthread_cancel to implement Thread.stop is an approach 
that may be doomed to failure (like a comment in the file says).

One reason is that Java threads can simply keep running if they
catch their death exceptions, but pthreads thinks the thread is on its
way out.  The effect of calling certain pthreads functions from
within a cancel cleanup handler is undefined.

Another problem is that throwing an exception out of a cleanup handler
might unwind the stack, destroying cleanup handlers further up the stack
which the threading system expects to execute.

A third problem is implementing JNI (if you ever do): since cleanup_push/pop
is lexically scoped, you'll have to go through a function like "really_start"
for every single JNI method invocation.

You already have to do that for the main thread after crt0 (though I don't
see that in the sources?  Does Thread.stop work for the main thread?
Do you use the OS main thread as the Java main thread?)

I have found pthread_cancel to be a very bad match for java's thread.stop().

> 
> Can't do this.  Even though Thread.stop() is deprecated, removing it is
> an API change, and the runtime will fail java compatability tests.

I'm sometimes wondering what these tests would look like, and if they
can be backed up by the spec.

The behavior of Thread.stop() is completely weird.  Take, for instance,
the fact that a thread that was stopped once will keep running if it
catches its death, but Thread.isAlive() will return false from then on.

> 
> 1) sounds fine to me.  Or just make it a no-op... my tests show it
> doesn't always work anyway (e.g. you can't stop() a thread waiting for a
> monitor).
> 

You mean you can't in libgcj or you can't in Java?
You can in Java, and you should be able to in libgcj.

It is true that the thread will reacquire the monitor before throwing 
the thread death exception, maybe that's what you meant? 

	- Godmar