[pylucene-dev] two different JCC modules in same VM; initVM()?

[Andi Vajda]

On Thu, 6 Mar 2008, Bill Janssen wrote:

>> You can also get this env value by calling getVMEnv() as in:
>>
>>   >>> import foo
>>   >>> foo.initVM(foo.CLASSPATH)
>>
>>   >>> import os, foo, bar
>>   >>> bar.initVM(classpath=os.pathsep.join([foo.CLASSPATH, bar.CLASSPATH]),
>>                   env=foo.getVMEnv())
>>
>
> This is close, but what I'd really like to be able to do call
> bar.getVMEnv() to get the environment.  I don't have a handle on foo
> at this point, and it would introduce a lot of coupling to keep one.
>
>> If the classpath resetting doesn't stick, try setting it to both in the
>> first initVM() call.
>
> Nasty coupling effect.  I don't want foo to have to know about bar,
> and I don't want bar to have to know about foo.

Yes, I agree but the coupling is there anyway since there can be only one VM 
running in your process. I don't have a process global variable in python to 
stick the vm handle into. The next best thing is to ask the module you 
'know' about.

Maybe I could stick the VM handle into a thread local variable on the main 
thread ? If there is no value, it's a new VM, if there is one, you add to 
it. The problem with that approach is that there are bunch of things about 
the VM you can't change once it's started and so there is likely to be a 
certain amount of coordination required between your modules so that they 
can all share the VM. For example, max stack and heap sizes come to mind.

In other words, making this less coupled is a losing battle anyway.
(apart from maybe the classpath setting which could be changed to be 
additive instead of replacing the current one). (this reminds me that I 
don't know at this time how setting the classpath this way interacts with 
the CLASSPATH env var, it's probably stomping on that too). (hence it's 
probably best to explicitely set classpath in initVM() to everything you 
want in it, at this time)

Andi..