Re: really_start vs _Jv_ThreadRegister?

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Adam" == Adam Megacz <gcj@lists.megacz.com> writes:

Adam> Hrm, for the FirstThread, it seems that really_start
Adam> (foo-threads.cc) never gets called.

Right.

Adam> What are the semantics for really_start -- is it guaranteed to
Adam> be part of the call path that starts the thread, or is it only
Adam> sometimes part of it? If only sometimes, when is it, and when is
Adam> it not?

`really_start' is just a convenience function.  The semantics are
whatever is convenient for the port in question.

Adam> Is really_start how you spawn a new thread, and
Adam> _Jv_ThreadRegister how you "bless" a platform-specific thread
Adam> into being a java thread?

The way you make a new thread is to create a new Thread object and
then use the `start' method.  Under the hood this will call
_Jv_ThreadStart.  This method is responsible for creating and starting
a new thread.

For instance, for ports like the posix-thread port which use
OS-provided threads, _Jv_ThreadStart creates a new OS thread and
starts it.  In posix-threads.cc, `really_start' exists just because
the callback function (the `meth' argument to _Jv_ThreadStart) returns
void, while pthread_create expects it to return `void *'.  Also we use
`really_start' to keep track of the non-daemon-thread count.


JNI or CNI code can tell the JVM about an already-existing thread.
This is done by calling _Jv_AttachCurrentThread.  This method creates
a new native thread object for the current native thread, and then
calls _Jv_ThreadRegister to do any platform-specific magic.  For
instance, the POSIX port uses this method to set the native->java
thread mapping for the current thread.  This is how _Jv_ThreadCurrent
works in that port.

Did you read the porting document for threads?  I don't know how
up-to-date it is, but it will probably help a bit.  Feel free to
submit bug reports against it.  I think using the `libgcj' category in
Gnats would be best.

Tom