[IronPython] What PythonEngine called my C# code? (was: custom ConfigurationSection in IronPython)
jvm_cop at spamcop.net
Thu Oct 5 06:29:43 PDT 2006
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
More information about the users