Re: CNI invocation API proposal

[Cedric Berger <cedric at wireless-networks dot com>]

Jeff Sturm wrote:

> On Fri, 13 Apr 2001, [iso-8859-1] Joerg Brunsmann wrote:
> >     1. Do we need to attach/detach threads to the GCJ JVM?
>
> I think so.  Java threads are native threads with a java.lang.Thread peer.
> For now the only way to get a Java thread is to create a new one; there is
> no means to bind an existing native thread to the gcj runtime.
>
> That means the primordial thread can never execute Java code.
> Currently the primordial thread does nothing but wait for all the
> non-daemon threads to terminate.
>
> The ugly part of JNI is that it allows a thread to detach from a different
> stack frame than it attached from.  If a thread detaches prematurely, any
> locks it holds must somehow be released.
>
> To avoid that I would prefer not to have both attach and detach methods,
> but rather a single method that will register the calling thread, execute
> a callback function, then unregister itself, similar to what JvRunMain
> does now (but without spawning a new thread).

Oops, this would be very, very expensive.
2 years ago, I was working on an application where I had:
  - a C library with a public API, which allowed you to register callbacks
   on status change (very much like add/remove listeners in java)
  - theses callbacks where called from a thread initialized by the C library.
  something like:

  lib_add_statuschange_handler(my_handler)
  lib_remove_statuschange_handler(my_handler)
then my_handler would be called by some thread, say 1000 times per second.

In my app, "my_handler" had to make a call into the java VM.

With this proposal (without the AttachThread function) this callback
would be very expensive (atttaching/detaching from the VM every millisecond
or so)

Cedric