CNI invocation API proposal
Fri Apr 13 11:08:00 GMT 2001
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.
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
More information about the Java