[Stackless] Reducing stackless footprint
Jacob Gorm Hansen
jg at ioi.dk
Mon Sep 3 11:17:20 CEST 2001
On Sun, Sep 02, 2001 at 03:59:55PM -0400, Mike C. Fletcher wrote:
> 2 -- If you're coding at the level of a state machine anyway, micro-threads
> sounds like overkill. After all, the state-transitions are already highly
> compartmentalised. You can just run through each object running its current
> state's handler. If you model the states as objects, then you can convert
> core/common functions to C/C++ when you discover they are choke points.
> Eventually, after you're sure the looping code is tight and right, you could
> push the dispatch code into C/C++ so that the core only calls out to Python
> for the custom code, with the heavy code sitting in a tight C loop.
> Micro-threads give you a way to do threading with some extra bells and
> whistles, that's a couple levels of abstraction above a state machine.
I'm not going to be using threads much in each state machine, but just need
the ability to timeslice each one, so that I can run a few of them for each
screen update, so I was thinking more along the lines of one thread per
state machine. Perhaps I might as well write my own scheduler, except I don't
really grasp the workings of continuation.timeslice yet, anyone have a small
example of how to use it? uthread.py seems to leak memory badly as well (try
it with 3000 randomly blocking threads to see what I mean).
> 3 -- 50 game logic operations is a pretty loose description. 50 simple
> "objects moving, maybe bouncing" logic operations would probably be quite
> doable with some vector logic operations in C. 50 "semi-autonomous
> characters with complex motivations, compound goal negotiation and
> resolution" logic operations is going to need some C/C++ services to take
> care of the heavy stuff with the Python code pretty much just modeling the
> data the services process with some custom code for exotic cases. It isn't
> Stackless that's likely to be a problem here (as far as I can see, since
> you've only got 50 micro-threads, not thousands), it's Python's speed that
> would be the limiter.
My scenario is the latter. But if only I can timeslice the state machines
the time should not be much of a problem. We are using a scripting language
for that already.
> 4 -- If I recall correctly, there's no current support for pickling, but I
> never tried. Pickling explicit state objects would likely be cleaner and
> more reliable.
Anyone know when that is coming? But ok, I might be able to live without it.
Stackless mailing list
Stackless at starship.python.net
More information about the Stackless