Hi Guido, all,
In the last months, I made very much progress with Stackless 3.0 .
Finally, I was able to make much more of Python stackless
(which means, does not use recursive interpreter calls) than
I could achive with 1.0 .
There is one drawback with this, and I need advice:
Compared to older Python versions, Py 2.2.2 and up uses
more indirection through C function pointers than ever.
This blocked my implementation of stackless versions, in
the first place.
Then the idea hit me like a blizzard:
Most problems simply vanish if I add another slot to the
PyMethodDef structure, which is NULL by default:
ml_meth_nr is a function pointer with the same semantics
as ml_meth, but it tries to perform its action without
doing a recursive call. It tries instead to push a frame
and to return Py_UnwindToken.
Doing this change made Stackless crystal clear and simple:
A C extension not aware of Stackless does what it does
all the time: call ml_meth.
Stackless aware C code (like my modified ceval.c code)
calls the ml_meth_nr slots, instead, which either defaults
to the ml_meth code, or has a special version which avoids
recursive interpreter calls.
I also added a tp_call_nr slot to typeobject, for similar
reasons.
While this is just great for me, yielding complete
source code compatability, it is a slight drawback, since
almost all extension modules make use of the PyMethodDef
structure. Therefore, binary compatability of Stackless
has degraded, dramatically.
I'm now in some kind of dilemma:
On the one side, I'm happy with this solution (while I have
to admit that it is not too inexpensive, but well, all the
new descriptor objects are also not cheap, but just great),
on the other hand, simply replacing python22.dll is no longer
sufficient. You need to re-compile everything, which might
be a hard thing on Windows (win32 extensions, wxPython).
Sure, I would stand this, if there is no alternative, I would
have to supply a complete replacement package of everything.
Do you (does anybody) have an alternative suggestion how
to efficiently maintain a "normal" and a "non-recursive"
version of a method without changing the PyMethodDef struc?
Alternatively, would it be reasonable to ask the Python core
developers, if they would accept to augment PyMethodDef and
PyTypeObject with an extra field (default NULL, no maintenance),
just for me and Stackless?
Many thanks for any reply - sincerely -- chris
--
Christian Tismer :^) <mailto:tismer@tismer.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
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