CNI invocation API proposal

Jeff Sturm jsturm@one-point.com
Wed Apr 18 11:51:00 GMT 2001


On Wed, 18 Apr 2001, [iso-8859-1] Joerg Brunsmann wrote:
> The naive idea with the above code fragments is
> that the gcj environment holds a table or even
> a configurable pool of threads. The clients
> ask the gcj environment for a instantiated
> and runnable thread which then acts as a wrapper
> for the native thread.

You must be careful to get Java thread semantics right.

What should happen to a java.lang.Thread instance after its native thread
is detached?  Does it behave as if the thread exited (i.e. isAlive returns
false)?  Do threads that are joining on it unblock?

Depending on the answer it may not be feasible to reuse a java.lang.Thread
instance.  My hunch is that over the lifetime of a java.lang.Thread it
must be mapped to at most one native thread.

Perhaps the simplest thing to do is not support detaching threads at all.
Apart from supporting JNI I can't think of a good reason for it.

Jeff




More information about the Java mailing list