Re: CNI invocation API proposal

[Jeff Sturm <jsturm at one-point dot com>]

On Fri, 13 Apr 2001, Cedric Berger wrote:
> > 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 that case it would be helpful to have that thread created by the VM, so
it has no need to attach.  What are the alternatives?  Hook
into GC_pthread_create so every thread is attached from the very 
beginning?  That assumes GC is linked into the executable, which may not
be the case, particularly for JNI.

Attaching an arbitrary thread from anywhere doesn't seem so easy to me.
How would the GC find its stack bottom?

The attach/detach operations need not be that expensive, I think.  But it
should allocate a new java.lang.Thread each time.  There might be some
other housekeeping necessary... hmm... what happens if a detaching thread
is being join()ed by another thread?  I think that once a thread detaches,
it should behave to the VM exactly as if it had terminated.

Jeff