really_start vs _Jv_ThreadRegister?

Wed Dec 12 11:01:00 GMT 2001

>>>>> "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