invocation interface

Tue May 15 21:00:00 GMT 2001

Per Bothner wrote:
> Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
>> > This interface is pretty much what I've had in mind. Note also that
> > there are runtime initialization functions which need to be run for GC
> > initialization etc, so AttachCurrentThread needs to check if the runtime
> > has been initialized yet and do so if neccessary.
>> My proposal is that you would have to call
> JvCreateJavaVM (NULL);
> before JvAttachCurrentThread. See my example program. JvRunMain
> also calls JvCreateJavaVM.

Do you think we need to require an explicit call to JvCreateJavaVM? If
JvAttachCurrentThread can do it implicitly then its one less thing for
CNI developers to worry about. In any case, I think it should to be safe to
call more than once, since someone may be calling it from a library routine
or such where it isn't always easy to guarantee singularity.
> I'm unsure whether JvCreateJavaVM should do PROCESS_GCJ_PROPERTIES.

It should - Java properties should still be settable
> > I am dubious about the benefits of getting rid of the FirstThread,
> > however. If it is going to make the invocation interface simpler to
> > implement, then thats cool, but please keep in mind that we need a place
> > to execute ShutdownHooks which will run even if the application is
> > shutdown abruptly by say ctrl-C or SIGTERM, and if possible we'd want to
> > implement that without using non-portable functions like
> > pthread_kill_other_threads_np().
>> Where are the shutdown hooks currently handled? I didn't see them
> in the code I changed.

They are not currently implemented but are something I'd like to have soon.
There are several places within the runtime where we should be using them to
do cleanups etc.
> Currently, FirstThread contains the getMain methods to find the
> main method of a jar. It seemed easier to keep that as Java code,
> but it might be reasonable to merge it with some other class.

By "FirstThread" I actually meant the "sentinal thread which sits in
_Jv_ThreadWait waiting for all other non-daemon threads to die", not the
gnu.gcj.FirstThread. The same behaviour could be acomplished by having each
thread check how many other threads are running when it exits, but I'm not
convinced that wouldn't make the code more complex and less portable.
I agree that the FirstThread functionality could be moved somewhere else, or
at least renamed.
regards
 [ bryce ]