Can you use the .Net stack trace mechanisms to "look back up the call stack"? I would think that you could, but I don't know how you'd necessarily get the value of the PythonEngine that you find.
Could you have a "static constructor" in your C# assemblies that does the right thing? Such code is called "at most once" which sounds like what you need. At 12:44 PM 9/20/2006, Jason Ferrara wrote >In my case I'm looking to write assemblies in C# that makes use of >modules defined in IronPython that others can use without having to >know or care that they use IronPython (except for having to have the >IronPython dlls around). Things are complicated by the fact that some >of the modules used need to have a single global environment. If C# >assemblies A and B both use IronPython assembly C, A and B need to >use the same PythonEngine or things won't work right. And if A and B >are being used from IronPython, then they need to use the >PythonEngine of the caller. > >So I guess I need some sort of magic that when a call is made into >the assembly it looks back up the call stack to see if there is a >PythonEngine, and if so uses that one. If not create its own and then >keep that one around for the next time the assembly is entered >without a PythonEngine in the call stack. > > >On Sep 18, 2006, at 12:11 PM, Dino Viehland wrote: > >> Probably the lack of an answer is due to the fact that there isn't >> a really great way to do this. Here's two possible ways to pull >> this off: >> >> For #1 you presumably kicked off the Python code via the hosting >> APIs, and therefore you know the engine that kicked it off. If you >> have multiple Python engines this might be tricky (if you have only >> one running on each thread at a time you could store it in a >> [ThreadStatic]). If you start getting into more complicated >> scenarios obviously this is going to break down quickly... >> >> For #2 you're looking at using ICallerContext. This is a bit of >> internal machinery that IronPython uses to flow state around for >> things that might need state (e.g. hiding CLR methods, locals(), >> exec, etc...). Off of ICallerContext there is both a SystemState >> and a PythonModule property. Unfortunately there's nothing that >> leads you directly to a PythonEngine. Instead you'd need to >> maintain a table of either modules->engines or SystemState (sys >> module) -> engines. >> >> #2 will work reliably if you control the creation of all engines in >> the process - the instance you go out of that it'll break down. >> The alternate plan here might be that having access to a >> SystemState and PythonModule you could already do some interesting >> things even though you don't have the full blown PythonEngine. >> It'd be interesting to hear if those are sufficient or if you >> really do need the engine in this case (and how horrible you think >> the 2 solutions are :) ). J. Merrill / Analytical Software Corp _______________________________________________ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
