At 9:52 12 Dec 2000 -0500, Rousseau, John wrote:
> It's a very strange model in which Apache sends a request to your
> module and you start up a VM to handle it. You probably should start
> your VM as a seperate process and use a socket to communicate.
I don't think this is so strange. While JServ/Tomcat works this way, it really
would be quicker to do this communication via JNI calls than pipe it across
another socket. There was an (attempt at) an effort to do this with Apache
open-source, I'm not sure where that's going...
> Why does Apache "not like" modules using libpthreads.so? It probably
> (very probably) uses it itself.
It seems to me that if it used it itself then there *wouldn't* be a problem.
For instance, you can't link a JNI library that uses pthreads against a Java VM
running green threads. But, if our JNI library uses pthreads & the Java VM
uses pthreads, everyone is happy.
> libhpi.so is the threading package. The one in native_threads is the
> LinuxThreads version. The one in green_threads (amazingly enough) is
> the Green (Sun's all-user-space package) threads version.
I agree that using green-threads (export THREADS_FLAG=green; might work) should
resolve this problem and make the JDK run with green-threads. But maybe this
uses other signals that will conflict with apache in some way? I'm guessing,
but this wouldn't surprise me very much at all.
After all that, I'm still in agreement with you about the outcome - do it in a
seperate VM, not using the invocation API. Yes, it's quicker, yes it will work
better on Windows (where all threads are equal ;), and yes it's more work. But
I'd expect some unstability to come from trying to do this in-process on Linux.
Paul
--
Paul Mclachlan ([EMAIL PROTECTED])
Software Engineer, Java Tools. NuMega Lab, Compuware corp.
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
