This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: CNI invocation API proposal
- To: Joerg Brunsmann <joerg_brunsmann at yahoo dot de>
- Subject: Re: CNI invocation API proposal
- From: Jeff Sturm <jsturm at one-point dot com>
- Date: Wed, 18 Apr 2001 14:56:09 -0400 (EDT)
- cc: java at gcc dot gnu dot org
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