This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: really_start vs _Jv_ThreadRegister?
Tom Tromey <tromey@redhat.com> writes:
> 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.
Ah, it's internal to foo-threads.cc. I see.
What if you're creating a Thread object for an already-existing OS
thread (ie the FirstThread case)?
> 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.
Yeah, this was the problem I was running into with win32. It only
created the mapping when _Jv_ThreadStart was called, so preexisting
threads never got mapped, so Thread.currentThread() was returning
null.
- a