Embedded python problem

[Robin Becker]

We have a client using a fully embedded python in a large DTP app. It used to be 
Mac OS 9/X only, but the MAC 9 support has gone away and we now have support for 
the PC with the embedding being used in C# via external DLL aliasing/marshalling 
etc etc.

The embedding DLL has effectively a single entry point called _run_string; this 
takes an LPStr string and with minor wrapping (to collect sys.stderr) is passed 
to an exec statement doing

exec code in __main__.__dict__

The client is having problems with a pair of executions looking effectively like

String 0
class C:
   .....
def F(a):
   ... C()....
import pprint
pprint.pprint(globals(),open('/tmp/dump0.txt','w'))


String 1
import pprint
pprint.pprint(globals(),open('/tmp/dump1.txt','w'))
F('namesonly')


The import pprint stuff is used to attempt to resolve the problem of F having 
vanished in the second environment.

 From the outputs dump0.txt/dump1.txt I can see that both C and F are defined at 
the end of 0, but at the beginning of 1 C still exists (and appears to have the 
same address), but F is nowhere to be seen. I'm guessing that someone is 
cleaning up somewhere, but could this be some .Net threading issue?

When I run this with a simple C# test harness it does exactly as expected and F 
exists.

I have suggested wrapping the function as a class instance with a __del__ method 
  having a stack dump to see if the function is deleted deliberately somehow, 
but that won't work if in fact the second environment is in fact not the same as 
the other. Is there some way to work out if I'm in the same interpreter if in 
fact we're joining the DLL in two places perhaps?
-- 
Robin Becker