Re: CNI invocation API proposal

[Joerg Brunsmann <joerg_brunsmann at yahoo dot de>]

Jeff Sturm <jsturm@one-point.com> wrote:

> Not quite... main_thread executes the Java main(), while the primordial
> thread (which called JvRunMain) waits for termination of all other
> threads.

Stupid question: if the gcj environment is created 
without a main function thread do we still need 
a "termination loop" which waits for termination of 
all other threads? Or will the gcj environment 
(javavm) will automatically be closed if all 
thread terminate?

> Normally JvAttach would return a Thread instance corresponding to the
> invoking thread (it may do nothing if the calling thread is attached).
> JvDetach would perform a longjmp, causing JvAttach to return NULL.  It
> would be possible for a native thread to attach once and never detach if
> desired.

Taking a clients perspective it should be easy to use.
If it is difficult to use for gij or jvgenmain that
would be ok; but it's not ok for all other non-java 
gcj clients. JNI isn't comfortable to use whereas
CNI is. What I mean with comfortable is the ability
of using object references and invoke methods on it.
If I'm able to say

  o->m();

it's easier, more readable and faster than

  env->invokeMethod("m");

If a CNI based approach doesn't allow one to use
object references to invoke methods then it doesn't
achieve more value than the JNI invocation API.

Leaving GC issues behind, the problem is still that
a non-java native thread can't be executed in the
gcj environment if it is not wrapped or registered
with a java.lang.Thread peer.

Taking the client perspective of simplicity 
a step further: a client wants something like

  // Registers the non-java native thread
  // if it is not already registered
  gcjEnv->mapMyNativeThreadToJavaLangThread();
  o->m();
  gcjEnv->unMapMyNativeThread();

or perhaps:

  class MyThreadClass : public ::java::lang::Thread {
    java::lang::Object *o;
    void init() {
      if (o == NULL) {
        o = Class::forName("...");        
      }
    }
    void run() {
      init();
      o->m();
    }    
  };

  java::lang::MyThreadClass * t = 
     gcjEnv->getJavaLangThread("MyThreadClass");
  t->start();  

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.

PS: Can't answer my emails for a couple of days.

Thank you,

Jörg



__________________________________________________________________
Do You Yahoo!?
Gesendet von Yahoo! Mail - http://mail.yahoo.de