Guido van Rossum wrote:
[setjmp/longjmp -no-no]
> Forget about it. setjmp/longjmp are invitations to problems. I also
> assume that they would interfere badly with C++.
>
> > I think just about any Scheme implementation has to solve this same
> > problem... I'll dig through my collection of them for ideas.
>
> Anything that assumes knowledge about how the C compiler and/or the
> CPU and OS lay out the stack is a no-no, because it means that the
> first thing one has to do for a port to a new architecture is figure
> out how the stack is laid out. Another thread in this list is porting
> Python to microplatforms like PalmOS. Typically the scheme Hackers
> are not afraid to delve deep into the machine, but I refuse to do that
> -- I think it's too risky.
...
I agree that this is generally bad. While it's a cakewalk
to do a stack swap for the few (X86 based:) platforms where
I work with. This is much less than a thread change.
But on the general issues:
Can the Python-calls-C and C-calls-Python problem just be solved
by turning the whole VM state into a data structure, including
a Python call stack which is independent? Maybe this has been
mentioned already.
This might give a little slowdown, but opens possibilities
like continuation-passing style, and context switches
between different interpreter states would be under direct
control.
Just a little dreaming: Not using threads, but just tiny
interpreter incarnations with local state, and a special
C call or better a new opcode which activates the next
state in some list (of course a Python list).
This would automagically produce ICON iterators (duck)
and coroutines (cover).
If I guess right, continuation passing could be done
by just shifting tiny tuples around. Well, Tim, help me :-)
[closures]
> > I think this is a great idea. I've been staring at python bytecodes a
> > bit lately thinking about how to do something like this, for some
> > subset of Python.
Lumberjack? How is it going? [to Sam]
ciao - 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