Jeremy Hylton <jeremy@alum.mit.edu>: > Are continuations necessary to implement them or are > there other options? I think you'll find that any implementation of microthreads or coroutines or whatever you want to call them, that doesn't rely on playing nonportable tricks with the C stack, will be just as mindbending as Stackless. > The problem is that continuations break the notion a C API call will > always return an answer; So do threads or coroutines. As soon as you have multiple threads of control, you have the chance that one of them will switch to another and never get back. > I assume Stackless raises an error in this case, > but this seems pretty messy This messiness isn't the fault of Stackless itself, but of the large amount of code which *hasn't* been converted to the Stackless Way. If the whole of Python and everything that it calls were made truly stackless, the problem would not arise. Doing so, however, would not be fun. It wouldn't be fun for any future extension writers, either. I can't see any way out of this. Continuations/coroutines/ microthreads are all basically the same thing underneath, and they imply an execution model that just doesn't fit well with C. Maybe we need to reimplement Python in Scheme, and then feed it through a good Scheme compiler. SPython, anyone? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4