Python microthreads

[Will Ware]

Tim Peters (tim_one at email.msn.com) wrote:
> ...you went out of your way to change ceval.c to use both
> brace and indentation styles Guido hates <0.9 wink>.

For my own private tinkering, I usually use the default indentation
modes offered by "indent" and Emacs C-mode. This is a matter of
laziness, not principle. If it ever mattered, I'd happily defer to
another style.

> Python already bytecode-slices "real threads" every N
> opcodes (set via sys.setcheckinterval)

That looks like the right way to do it. Thanks for pointing
that out.

> ...fake threads of any flavor [would, without enormous effort] all
> block at I/O calls.

I envision using microthreads for dumb little agents in swarm-like
simulations (game examples: robot tanks, PacMan monsters) where
nothing like file I/O would ever come up. But yeah, it would be good
if there were eventually some documentation with discussion of
limitations.

For those who want to follow along at home: A PyThreadState has two
relevant fields. tstate->ticker counts down executed bytecodes
starting from tstate->interp->checkinterval, the same thing my
num_steps counter is doing, except that all the machinery already
exists in the core release. sys_setcheckinterval(), defined in
sysmodule.c, sets tstate->interp->checkinterval. "ticker" is a field
of a PyThreadState, "checkinterval" is a field of a
PyInterpreterState, both defined in Include/pystate.h.

The use of "ticker" as a bytecode-slicing mechanism is enabled by a
static flag called "things_to_do" in ceval.c. My "uthread.step"
function would need to set things_to_do, call eval_code2_loop, and
reset things_to_do to its prior state. I'm not yet sure how to handle
threads whose status is "still working". Maybe I need to add a
WHY_STILLWORKING enum value, and possibly flag the thread or frame in
some way to represent that status.
-- 
 - - - - - - - - - - - - - - - - - - - - - - - -
Resistance is futile. Capacitance is efficacious.
Will Ware	email:    wware @ world.std.com