[MUD-Dev] Embedding Python

icecube at ihug.co.nz icecube at ihug.co.nz
Sat Feb 12 21:30:17 CET 2000


I'm looking at embedding Python in at least one mud, and there are a few
practical issues I've run into with the standard Python codebase. Given
that there are members of mud-dev who seem to be doing similar things, I'm
hoping I can avoid reinventing the wheel as much as possible here :) 

The basic structure I want is the core C++ code calling Python code when
events occur within the game. Python->C++ calls will be brief and
essentially limited to thread management and game object modification.

Potentially all Python threads can be long-lived, reacting to later
events. The server is single-threaded so manually suspending and resuming
the threads is needed. I'm currently looking at a model similar to the
ColdC/Genesis thread model - no preemptive thread switching, but limits on
execution time without allowing a context switch. 

I need to be able to catch runaway execution. A simple ">x bytecodes
executed since last context switch" would do. It might be nice to have a
"warning" exception so intermediate levels of Python can at least tell the
user what happened while trying to do something. The Python microthreads
extensions [1] seems to allow this. 

I need to be able to suspend a thread of execution in mid-stream, either
waiting on some external event (eg. player input arriving) or to allow a
context switch. Stackless Python [2] looks like it can handle this, since
it can already handle continuations and coroutines.

Stackless Python and microthreads are apparently on the path to
integration, but they're not there yet. It looks non-trivial to do
especially without knowing the guts of the Python interpreter in detail
(which I don't). 

Garbage collection is an issue since standard Python has a simple
refcounting scheme that won't detect reference cycles. There are a couple
of solutions for this around [3] although I haven't actually tried them.

Excessive memory use may be an issue. It would be nice to be able to
"charge"  python code for memory allocation it causes, and catch runaway
allocation before Bad Things happen. I'm not sure where to begin with
this!

Anyone working along the same lines and would like to share their
insights?

--
Oliver Jowett - icecube at ihug.co.nz - http://homepages.ihug.co.nz/~icecube/
KeyID: 1024/679D94C5  Fingerprint: CD94 5270 E2F4 339F 6A90 05C9 9DE4 EECC

[1] Python microthreads -- http://world.std.com/~wware/uthread.html
[2] Stackless Python -- http://www.tismer.com/research/stackless/
[3] Python GC -- http://www.acs.ucalgary.ca/~nascheme/python/gc.html



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list