[Python-Dev] Stackless Python
Bob Ippolito
bob at redivi.com
Mon May 31 16:08:51 EDT 2004
On May 31, 2004, at 3:33 PM, Martin v. Löwis wrote:
> Bob Ippolito wrote:
>> Although I don't particularly agree with that, because Stackless
>> functionality could be turned on and off with a platform dependent
>> configure flag (like threads or unicode)... Is there a canonical
>> list of CPU architectures and platforms that Python officially
>> supports?
>
> No - although there is a list of platforms, that Python *doesn't*
> support (PEP 11). Python is written in C, so it should work on any
> system that supports ISO C, although many functions won't be available
> if the system doesn't support POSIX.
>
> As for turning of things: yes, unicode can be turned off, but not
> because the platform doesn't support it - rather because the
> administrator doesn't like unicode. Threads are turned off on operating
> systems that don't provide threads, and there is nothing that Python
> could do about it.
>
> Stackless' support for platforms is different: it includes assembler
> code, so you have to write bits of assembler code for each architecure
> (and perhaps for each system on a single architecture, or even each
> assembler on each system).
I don't see how including a little bit of
per-architecture-calling-convention assembler code is much different
than depending on pthreads (or some other platform dependent thing)
being present. There is also potentially a platform neutral way of
doing it (see below).
> [In addition, the approach taken by Stackless 3.0 is probably
> questionable: for example, it may be that C++ exception handling
> stops working in Stackless.]
I'm not quite sure you are up to date on how Stackless 3.0 works. The
assembly code is only there to facilitate "hard switching", which is
only required to do tasklet switching in the face of some C extension
that doesn't know about Stackless. The vast majority of tasklet
switches use the "soft switching" mechanism, which just means that the
code they use is capable of going into non-recursive mode. All pure
Python code and almost all code built-in to Python goes through "soft
switching", which is implemented in pure C with no stack tricks or
anything. Stackless would still be a very useful addition to Python
even when "hard switching" is not available.
Alternatively, Armin believes that Stackless "hard switching" can
actually be implemented in mostly-platform-neutral C (either by
setjmp/longjmp or alloca hacks, I forget which) and has a prototype
implementation in the Stackless CVS repository (though it is not
integrated with Stackless itself). It might also be possible to coerce
something like libffi into doing what we need it to do.
I'm not sure how well "hard switching" would play with an operating
system that is very protective of its stack, like OpenBSD or future
versions of Windows, though.
I'm also not sure how it could "break C++ exception handling" in
scenarios where it wouldn't be broken anyway. I'd like to see a test
of that that passes under regular Python but fails in Stackless for
this.
-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-dev/attachments/20040531/e89b3b0e/smime.bin
More information about the Python-Dev
mailing list