I did some experiments with trying to add continuations to Python in
order to support coroutines and threads. My belief was that the best
most portable way to support threads would be to support it in the
language/interpreter without requiring OS support.
The interpreter frames have almost enough context to be a continuation. I
think I only added one of two fields and some support to save and restore
them. Frames and most other interpreter objects "under the hood" are real
python heap allocated objects, so they can be caught and preserved.
However, Guido and Tim Peters were correct, it seems, in their warnings
that the problem would be the mixed nature of Python and C code in a
typical Python app. I was willing to have coarse threads - not
finer than one or more Python instructions. But since Python code can
call C code and C code can call Python code, my scheme wasn't really
workable for arbitrary code.
I'm convinced a modified version could be made workable - but it would
be a bigger modification than I had originally envisioned. And since
more and more platforms are going to be supporting threads in the OS,
I'm not sure it's worth the effort. I also suspect that Guido's
implementation of threads in Python was also guided by what looked like
a "doable hack" - i.e. it could probably be done better if you started
from scratch, but that wasn't practical at the time.
---| Steven D. Majewski (804-982-0831) <sdm7g@Virginia.EDU> |---
---| Computer Systems Engineer University of Virginia |---
---| Department of Molecular Physiology and Biological Physics |---
---| Box 449 Health Science Center Charlottesville,VA 22908 |---