MUD servers and microthreads (was Re: Last question of the day (This one's easy!))

[Amit Patel]

 Martijn Faassen <m.faassen at vet.uu.nl> wrote:
| 
| I've done some thinking about the use of Python as a mud server language
| as well, and I suspect it's well up to the job. Compare for instance with
| Zope (www.zope.org), which implements a dynamic *web* server in Python. If
| you can do that, you can do the same for muds. Of course Zope has parts
| written in C for speed, but you can do that for a mud server too, if
| necessary.
| 
| Also compare with lpc of lpmuds, which you mentioned. I doubt lpc code can
| run that much more quickly than python code (if at all), and lpmuds have
| been around for years now and work just fine.
| 
| Python has a lot of exciting technologies that would make building a mud
| easier. Lots of standard stuff is already done for you, for one. Then there
| are interesting things like the Zope object database which you may want to
| use to build a persistent database for a mud. There's all sorts of things to
| make Python talk to remote methods as well (CORBA, XML-RPC, etc).
| 
| My main concern with using Python as a mud server is infinite loops, and
| costly methods in general. A mud shouldn't 'hang' when some coder inside
| happens to code a buggy object with an infinite loop in it. Instead the
| mud should detect a method is costing way too many ticks (or bytecode
| executions) and abort it. I've seen two main ways to get around this; one
| is Zope's approach; basically it limits its DTML so that you can't write
| infinite loops. I don't much like this one for muds, as you'd like people
| to use Python to extend it.
| 
| Another possibility is to do something like Will Ware's microthreads do;
| they work by using the 'tick' approach and thus even if one thread loops
| infinitely the rest is still fine. Unfortunately microthreads depend on
| a module that contains a patched Python interpreter loop, which isn't
| exactly easy to maintain..
| 
| I only have limited knowledge about how full fledged multithreading can
| help here, perhaps someone else can give an answer.
| 
| I've also been curious how Joe Strout gets around this problem in his POO
| (a MOO inspired Python based mud).

As far as I know, POO does not deal with this problem at all, nor does
it support the MOO commands fork() or suspend().  That's the main
reason I stopped using POO (the other being that I'm used to MOO, in
which all non-objects are immutable, and Python's mutable data just
made it too easy for one user to mess up another user's data).  I do
way too many neat things with fork() and suspend(), and not being able
to create new background tasks was too limiting.  :(

I think microthreads/coroutines would be the right way to do this.
It'd be nice to write the scheduler yourself so that you can maintain
some kind of load balancing among users (i.e., one user with 10000
tasks gets the same CPU time as another user with 3 tasks).  You'd
also like to save the execution state somehow and checkpoint it all to
disk, for those rare cases when the server has to go down.

      - Amit