On Mar 4, 2011, at 11:34, Bill Janssen <jans...@parc.com> wrote: > Andi Vajda <va...@apache.org> wrote: > >> >> On Fri, 4 Mar 2011, Bill Janssen wrote: >> >>> Andi Vajda <va...@apache.org> wrote: >>> >>>>> Or if I need to run the same Python program multiple times? >>>> >>>> There is no notion of python program in this context (no >>>> __main__). You import a module, instantiate a class from it and invoke >>>> its methods. You can import and instantiate as many classes and >>>> modules as you like, of course. >>> >>> JEPP has an interface to Python's "exec". This avoids the overhead of >>> writing a Java class which is then subclassed in Python which is then >>> instantiated and brought out to Java again so that you can call one of >>> its methods. That would be a handy thing to have in PythonVM. I >>> suppose I could add it, after I get PythonVM working (this loadLibrary >>> thing). >>> >>> Alternatively, I could use JEPP, or JEPP tweaked for JCC, if there was >>> some way to pass the Java VM "into" the JEPP instantiation of Python, in >>> such a way that that initVM() could find it. >> >> If JEPP execs python, then that Python VM runs in a subprocess of the > > It's not Java's Runtime.exec(), it's Python's built-in function, "exec". > So the Python VM is running in the same address space as Java.
Ok, so how is JEPP doing this from Tomcat without patching the Tomcat startup code so that the PythonVM is initialized in the main thread ? If what you say is true then how is that different from what Roman is doing with JCC and Python's subprocessing module ? Andi.. > >> Java process. If you then call JCC's initVM() from that subprocess, I >> do not know how the JNI api would behave in that situation. Will it >> "find" the parent process' JVM, I don't know. I doubt that JNI has all >> the magic required for transparent IPC to the parent process built-in >> out of the box. > > Right. If I was going to do that, I'd just use java.lang.Runtime.exec(). > > Bill
