Tim Peters wrote:
>
> [Tim]
> > OK. So how do you feel about coroutines? Would sure be nice
> > to have *some* way to get pseudo-parallel semantics regardless of OS.
>
> [David Ascher]
> > I read about coroutines years ago on c.l.py, but I admit I forgot it all.
> > Can you explain them briefly in pseudo-python?
>
> How about real Python? http://www.python.org/tim_one/000169.html contains a
> complete coroutine implementation using threads under the covers (& exactly
> 5 years old tomorrow <wink>). If I were to do it over again, I'd use a
> different object interface (making coroutines objects in their own right
> instead of funneling everything through a "coroutine controller" object),
> but the ideas are the same in every coroutine language. The post contains
> several executable examples, from simple to "literature standard".
What an interesting thread! Unfortunately, all the examples are messed
up since some HTML formatter didn't take care of the python code,
rendering it unreadable. Is there a different version available?
Also, I'd like to read the rest of the threads in
http://www.python.org/tim_one/ but it seems that only your messages
are archived?
Anyway, the citations in http://www.python.org/tim_one/000146.html
show me that you have been through all of this five years
ago, with a five years younger Guido which sounds a bit
different than today.
I had understood him better if I had known that this
is a re-iteration of a somehow dropped or entombed idea.
(If someone has the original archives from that epoche,
I'd be happy to get a copy. Actually, I'm missing all upto
end of 1996.)
A sort snapshot:
Stackless Python is meanwhile nearly alive, with recursion
avoided in ceval. Of course, some modules are left which
still need work, but enough for a prototype. Frames contain
now all necessry state and are now prepared for execution
and thrown back to the evaluator (elevator?).
The key idea was to change the deeply nested functions in a
way, that their last eval_code call happens to be tail recursive.
In ceval.c (and in other not yet changed places), functions
to a lot of preparation, build some parameter, call eval_code
and release the parameter. This was the crux, which I solved
by a new filed in the frame object, where such references
can be stored. The routine can now return with the ready packaged
frame, instead of calling it.
As a minimum facility for future co-anythings,
I provided a hook function for resuming frames, which causes no
overhead in the usual case but allows to override what a frame
does when someone returns control to it. To implement
this is due to some extension module, wether this may
be coroutines or your nice nano-threads, it's possible.
threadedly yours - chris
--
Christian Tismer :^) <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net
10553 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
we're tired of banana software - shipped green, ripens at home
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