Date: Mon, 19 Nov 2001 12:15:56 -0800 From: Joe Kelsey <joe@zircon.seattle.wa.us> To: Bill Huey <billh@gnuppy.monkey.org>, freebsd-java@freebsd.org Subject: Re: Plugin status Message-ID: <15353.26748.393858.772996@zircon.zircon.seattle.wa.us> In-Reply-To: <20011119113153.B7857@gnuppy> References: <15353.18978.717379.778079@zircon.zircon.seattle.wa.us> <20011119113153.B7857@gnuppy>
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Huey writes:
> On Mon, Nov 19, 2001 at 10:06:26AM -0800, Joe Kelsey wrote:
> > We can solve the nspr4/mozilla problem by including a copy of the i386
> > nspr4 library in
> > j2sdk1.3.1/plugin/.oji-plugin/src/motif/lib/solaris/i386/libnspr4.so as
> > part of the port. It's up to Greg.
> What is that library ? a pthreads abstraction layer ?
nspr=NetScape mumble, mumble...essentially the netscape standard calling
sequences...
> I wasn't sure that the plugin worked with anything other than native
> threading. Any quick pointers to the sources for it off hand so that I
> can look how it would interact with the JVM's threading systems
> (native, green) ?
The plugin itself has nothing to do with threading model.
libjavaplugin_oji.so is merely a method of creating a child process
(fork) with several pipes open to the Mozilla parent for passing
requests back and forth. The parent (Mozilla) does not actually include
a jvm in it's address space. The child process is essentially the
executable java_vm using whatever threading model is specified by the
environment variables (THREADS_FLAG in the parent is transformed into
THREADS_TYPE for the child). It should make no difference what thread
model is used in the child, as the only thing plugin-related is entirely
contained in
j2sdk1.3.1/ext/plugin/oji-plugin/src/motif/jvm_{exec,natives}/*, which
are used to build the executable java_vm, which is installed in the jre
lib hierarchy.
If you look at
j2sdk1.3.1/ext/plugin/oji-plugin/src/motif/jvm_exec/java_vm.c, you will
see where the plugin fails in its current state. This is a very simple
file and only sets up the environment for the jvm to run in. According
to my traces, it gets as far as printing the JNI_VERSION and calls the
function JNI_CreateJavaVM, but somehow fails during that function,
killing both the child and parent mozilla processes.
As far as I know, there is nothing controversial about the trace or the
processing. It is entirely possible that I am missing something. I
believe that the JNI_CreateJavaVM function is in libjvm.so, a standard
library.
/Joe
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-java" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15353.26748.393858.772996>