There's two ways I can think of how to enforce the time limit: 1. An external monitor which aborts the thread when a quantum has expired. This has the problem of potentially aborting at any native CPU instruction which most code is in no way prepared to handle. Therefore
2. Update CodeGen to emit checks to see if the current quantum has expired. Most likely you'd want to do this on every back-branch within the IL. I'm not sure how exactly you'd detect that w/o putting an abstraction around the Label structure so you know where each label lives within the IL. For compiler generated loops which you know to be bounded you could eliminate the check also and only do it for user defined loops. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Markus Hajek Sent: Friday, April 06, 2007 6:33 AM To: [email protected] Subject: [IronPython] Restricting IronPython Hi, I'm evaluating IronPython for use as a scripting language in a game server. Designers would use it for game-logic. Because designers typically are not engineers, one cannot expect them to follow common good practices. So I need to restrict what their script code can do in a few ways: a. They should not be able to use any libraries other than what we expose to them explicitly. That includes Python libraries (other than local) and .NET-Framework libraries. b. For framework classes it's necessary to expose only certain members of these classes that are meant to be used from Python. c. It should be possible to time-limit execution time of a script. Designers might build scripts that under certain circumstances enter an infinite loop or something similar. In such a case, script execution should be aborted. Now with a) it's easy enough to take away access to Python libraries. Neither is there a problem with .NET framework stuff because you need to add a reference explicitly - with two exceptions, mscorlib.dll and system.dll are referenced automatically. I wrote a patch to get around this (PythonEngine and ReflectedPackage). With this patch you have two boolean properties in EngineOptions, AutoReferenceMscorlib and AutoReferenceSystem which by default are set to true to keep behavior as it is, but can be set to false, too, with the expected effect. For b) it turns out there is no easy way of having a framework classes expose only certain methods/properties by for example passing only an interface to Python. That just doesn't work because Python will allow access to any public member of the concrete instance. One way around that would be to write adapter for each framework class (like: for class Player create class PythonPlayer which holds an instance of Player as private member and exposes only those members publicly that should be visible from Python), but that would be tedious. So I created another patch (Attributes and ReflectedType) which adds a new attribute [DoNotExpose] to IronPython. Framework code writers can decorate properties, methods, fields, nested types etc. with this attribute. Members decorated such won't be visible to Python code. Again, by default behavior is not changed as no code has this attribute. With c) I am stuck. I'm not at all sure where I could add such functionality with minimum impact to the existing codebase. Any ideas on that? Besides, any feedback to the patches would be most welcome, too. Happy Easter holidays, Max Hajek Vienna
_______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
