Limiting thread intruction count

[Tim Peters]

[Neil Macneale, wants to limit ...

   Yes, bytecode intructions.
]
> ...
> So round robin scheduling is automatically used?  The game is being
> written strictly for unix;  is there a way to find out if the unix
> version uses round robin scheduling?

On any platform with thread support, Python code runs under the protection
of a global interpreter lock (GIL), which gives a thread exclusive access to
the Python Virtual Machine for a fixed number of bytecodes.  You can alter
that magic number by calling sys.setcheckinterval().  Say you set it to 100.
Then every 100 bytecodes, the eval loop forces the current thread to release
the GIL, allowing some other thread to acquire it.  Python has no control
over *which* thread gets it next -- since Python threads are real OS
threads, that's up to the OS thread implementation.  So is it round robin?
Beats me, and, more importantly, beats you too <wink>.

The Stackless Python variant

    http://www.stackless.com/

implements a notion of (pseudo)microthreads instead, which may be more to
your liking.  They're not related to OS threads at all, and typically enjoy
much lower memory consumption and much faster context switching than "real
threads".  Also more potential for influencing exactly when they swtich.

Note that "a bytecode" is a very high-level thing in Python, and number of
bytecodes has no clear relationship to elapsed time.  For example, one
bytecode may add 1+1, while another may sort a million-element list.