However, one of my other points burried somewhere in that discussion
was that threads could be supported more portably by building
coroutines into the interpreter virtual machine. Python byte-code
instructions and builtin-C functions would then be 'atomic'. ( This
has some good and some bad implications, which I haven't thought thru
yet. ) Whether a coroutine/continuation syntax should show thru to the
Python language level is another question. I'm interested in exploring
that option, but the two questions are independent.
> 2) General continuations may be much harder to implement than we thought,
> because the state of the _C_ runtime stack is also part of the current
> continuation, and that's hard to muck with short of low-level OS- and
> machine-specific hacks. I can picture an elaborate scheme to worm
> around that, also using threads, but ...
But that's the point: because C-functions and python byte-code
instructions are atomic, the _C_ runtime stack is NOT a part of the
context or current continuation - only the Python block and argument
stacks and the current byte-code instruction pointer. We only have to
keep state for the virtual machine - that's what makes it portable.
> Disagree with either of those?
Yes. [ see above! ]
> The more I see of general continuations
> the less I want to see them as part of Official Python, but I do think
> they'd be fascinating to play with. I've been surprised before!
I've finished my sci-fi book, so my silence on these matters has been due
mostly to the fact that I'm actually tring to figure out an implementation so
I CAN play with it. If I give up on coroutines and/or continuations in
the *language*, my fall back is to try to support portable threads via
this mechanism.
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics