From owner-freebsd-java Mon Nov 19 12:14:43 2001 Delivered-To: freebsd-java@freebsd.org Received: from zircon.seattle.wa.us (sense-sea-CovadSub-0-228.oz.net [216.39.147.228]) by hub.freebsd.org (Postfix) with SMTP id 3105937B416 for ; Mon, 19 Nov 2001 12:14:41 -0800 (PST) Received: (qmail 96259 invoked by uid 1001); 19 Nov 2001 20:15:56 -0000 From: Joe Kelsey MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15353.26748.393858.772996@zircon.zircon.seattle.wa.us> Date: Mon, 19 Nov 2001 12:15:56 -0800 To: Bill Huey , freebsd-java@freebsd.org Subject: Re: Plugin status In-Reply-To: <20011119113153.B7857@gnuppy> References: <15353.18978.717379.778079@zircon.zircon.seattle.wa.us> <20011119113153.B7857@gnuppy> X-Mailer: VM 6.96 under Emacs 21.1.1 Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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