[IronPython] Suspending, saving script execution?

[Erzengel des Lichtes]

Thanks for the responses,

I've considered using yield, which is what drew me to Python in the first
place, but I operate under the theory that the developer should make it as
easy as possible for the user, not themselves. Which means I need to do the
yielding automatically on the C# side.

What I really want is to use the reflectance available in .net, but I don't
need the script itself to be turned into MSIL. The script should be able to
be suspended anywhere in the script so that I can save/load (and prevent
hanging by interrupting a long script, then let it continue after other
scripts have had a chance to run). On the other hand, all .net methods will
be atomic.
I don't really care much about the performance of the scripts as they're
supposed to be very high level; everything performance critical is written
in C++, and everything else (except AI and scene choreography) is in C# (the
glue is in C++/CLI). Only AI, scene choreography, and user scripts are in
python. More often than not, a python script will probably be in its
suspended state, waiting for "move" or whatever to return. The script's
performance isn't much of a concern when the script isn't actually doing
anything most of the time.

Up until now I've just been looking into completely replacing PythonEngine,
just using Compiler.Parser, but I'll look into Compiler.Generation.CodeGen,
as well. I just haven't become very familiar with the internals of
IronPython so any pointers would be appreciated (at the moment, I'm just
following execution in the debugger).

Erzengel des Lichtes
Hikari no Daitenshi
Archangel of Light

-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Monday, January 29, 2007 1:48 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Suspending, saving script execution?

Presumably someone could also modify IronPython's CodeGen class to turn all
methods into generators that yield at regular intervals.  This would take a
significant performance hit as all the locals would be hoisted into a
FunctionEnvironmentDictionary and would still need the scheduler / virtual
stack maintenance but be an interesting experiment.

-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Hogg, Jonathan
Sent: Monday, January 29, 2007 1:02 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Suspending, saving script execution?

Stackless Python is definitely the way to go, but if you needed to do this
in IronPython/.NET, you can get a poor man's form of micro-threading with
generators. Taking your example, you could re-write it like so:

def main(self):
    yield move(5)
    yield turn(90)
    if self.direction == Direction.East:
        yield turn(180)
    yield move(2)

where 'move' and 'turn' are type constructors - or factory functions or
whatever - that return an object representing the action to be taken.
Now you instantiate the generator to create your micro-thread, and call
'.next()' on it to execute it up to the next yield.

t1 = mytank.main()
action = t1.next()

The difference between this and full threading is that it's cooperative and
that you have to write your own micro-thread scheduler. Presumably you'll
have some kind of game-state/event engine that will keep track of what each
of the actors is currently doing and when they become eligible for execution
again (it's finished moving/turning), you would poke them to see what they
want to do next.

Main problem is that if a piece of user-generated logic is badly behaved
(doesn't yield), then your game would hang.

Jonathan

________________________________

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher
Sent: 28 January 2007 17:37
To: Discussion of IronPython
Subject: Re: [IronPython] Suspending, saving script execution?


On 1/28/07, Erzengel des Lichtes <erzengel-von-licht at cox.net> wrote:

        Now, the script is going to need to be suspended while it's moving 5
meters
        (it's not going to teleport) forward, then again while it's turning
90
        degrees to the right, possibly again when it turns around, and
finally once
        again while moving forward 2 meters.
        I can't block the script without suspending the thread/fiber, right?
But
        with a large number of scriptable units, the system will not be able
to cope
        with a thread/fiber per script.


This sounds like the sort of thing that Stackless Python[1] was invented
for.  This is a variation of CPython that -- by removing the dependency of
Python code execution on the processor's stack -- allows execution of
multiple objects without creating multiple threads.  The game "EVE Online"
uses Stackless Python for this purpose.

I doubt you could accomplish something similar in IronPython simply because
of how the CLR works.  But the low-level hooks in CLR 2.0 that were created
for SQL Server may allow something in that direction.

1: http://www.stackless.com
2: http://www.eve-online.com

--
Curt Hagenlocher
curt at hagenlocher.org

--
This message may contain confidential, proprietary, or legally privileged
information. No confidentiality or privilege is waived by any transmission
to an unintended recipient. If you are not an intended recipient, please
notify the sender and delete this message immediately. Any views expressed
in this message are those of the sender, not those of KBC Alternative
Investment Management Limited or its affiliates, or any funds or accounts
managed or advised by any of the aforementioned entities (together referred
to as "KBC AIM").

This message does not create any obligation, contractual or otherwise, on
the part of KBC AIM. It is not an offer (or solicitation of an offer) of, or
a recommendation to buy or sell, any financial product. Any prices or other
values included in this message are indicative only, and do not necessarily
represent current market prices, prices at which KBC AIM would enter into a
transaction, or prices at which similar transactions may be carried on KBC
AIM's own books. The information contained in this message is provided "as
is", without representations or warranties, express or implied, of any kind.
Past performance is not indicative of future returns.

_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com