Python share CPU time?

[neokosmos at gmail.com]

alex23 wrote:
> Simon Forman wrote:
> > This is just a dim memory, but something called lambdaMOO was (is?) a
> > Multi-User Dungeon that had (has?) a model of processing that allowed
> > you to create programmed objects that received a "budget" of processor
> > time.  The objects would not work if they "ran out" of processor
> > time...
>
> It basically employs its own threading model to do just this.
> SecondLife does much the same: any system that allows for the apparent
> parallel running of code will.

IIRC, LambdaMOO's threading model is based on cooperative multitasking,
possibly with the ability to limit how many VM-level instructions a
piece of code executes per timeslice (I'm not intimately familiar with
it).  However, such an ability to limit how many instructions are
executed per timeslice really requires VM-level support.

In LPMUDs, which I am much more familiar with, and which also implement
a similar cooperative multitasking "thread model" (I put this in quotes
because it's not really threading -- it's actually a near equivalent of
generator-based microthreads), it's still possible to lag the game for
long periods of time with any reasonable limit on the number of
instructions per "tick."  That might not matter much for a hypothetical
Python-based robot game, if it weren't designed to be interactive.

> LambdaMOO still exists, incidentally! You might also be interested in a
> python-implemented version of the main MOO core, the unfortunately
> named POO: http://www.strout.net/python/poo/

I believe POO's "thread model" is much the same as I've described
above: inherently it's cooperative multitasking.

Incidentally, if you don't like the name POO, there's also MOOP at
moop.sourceforge.net.  I don't know if MOOP is derived from POO, but
they have similar descriptions and aims, so I wouldn't be *too*
surprised.