Python microthreads

[Tim Peters]

[Will Ware, on his microthreads vs Christian Tismer's Stackless Python]
> ...
> Yes, they're independent. Christian has already been in
> consultation with the gods of Python, so I think his work is
> more in the mainstream spirit of the Python codebase.

So far Guido has neither embraced nor rejected it; still a work in progress,
of uncertain outcome.  OTOH, your changes will never go in, because you went
out of your way to change ceval.c to use both brace and indentation styles
Guido hates <0.9 wink>.

> I don't think CPython loses anything by being stackless,

So far it has lost a little speed.  That can probably be regained.  Part of
Christian's agenda is seeing what it would take to implement 1st-class
continuations (in the Scheme sense) too, and his frame manipulations are
general enough to support that, and that costs something beyond mere
stacklessness.

> so maybe stacklessness could be folded into the core release.

Definitely the hoped-for outcome.

> So implementing microthreads separately will become an increasingly
> bad idea.

Yup.  You would gain some nice properties too; e.g., you could lose the
hardcoded limit on frames per thread, and run many more threads because the
control structure for each could be much smaller thanks to not preallocating
space proportional to that max # of frames.

> I don't know if Christian's version of eval_code2 can be
> stepped a controlled number of opcodes.

There's no direct provision for that now.

> That would need to be done for microthreads.

Python already bytecode-slices "real threads" every N opcodes (set via
sys.setcheckinterval); you probably didn't need to invent another mechanism
for that, and it's more efficient to hijack the one that's there (checking
two counters per eval-loop trip is twice the pure overhead of checking one
...).  So this one doesn't seem "deep".

Guido has let on that his primary objection to fake threads of any flavor is
that-- without an uncertain amount of additional widespread work --they'll
all block at I/O calls.  If you think threads are good only for overlapping
I/O (with other I/O or with computation), that's a killer objection.  I
personally see lots of uses for threads, but almost none for I/O <wink>.

doing-i/o-is-like-picking-someone-else's-nose-ly y'rs  - tim