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
