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 :) ). > _______________________________________________ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
