[Python-Dev] Stackless Python

[Christian Tismer]

Phillip J. Eby wrote:

> At 06:34 AM 6/1/04 -0700, Guido van Rossum wrote:
> 
>> > It is most probably possible to implement soft-switchign in Jython.
>>
>> That's a rather vague statement; I'd like to hear from Samuele about
>> that.

I believe it is doable, and I'll ask him. If java can use
something like function pointers, it is possible. If you have
to have compiled calls all the time, well, I did not invent Java,
and I don't want to know who was it. (Actually I do :)

Me:

>> > No idea what you mean by arbitrary exceptions (I never had that)
>>
>> I meant exceptions to the general rules.  Like, you can't depend on
>> tasklet switching when you use one of these extensions, or one of
>> these built-ins, or ...

This is out of date stuff, related to 2.0 where everything was
hard-switched. Soft-switching has none of these problems.
Hard switching between tasklets doesn't have this, too, provided
that you don't leave a context without a consistent exception state.
I do this consistently with Python: never leaving a Python exception
around across a switch, everything is packed up. If a user tells me
about a problem in the context of C++ exceptions, I will build
the necessary framework to make this consistent. it just didn't happen,
yet.
But in the general case, there is nothing like this. If you switch
between tasklets, this is like switching between threads. If your
code tries to access stack memory from a different thread while
running your thread, your code is flawed, not Stackless.

...

Philip:

> Anyway, I don't know about "the users" in general, but for me at least 
> tasklets are where it's at.  :)  And I only care about explicit 
> yielding, not thread-like concurrency.  (IOW, I don't want Stackless 
> doing the scheduling, I'd want to be able to write my own scheduler, in 
> pure Python.)

You can have it both, some like auto-scheduling, most dislike it
(as I do). This is all configurable at runtime, and by default,
nothing is scheduled unless you explicitly ask for it.

>> > I understood it more like the more advanced question "why does
>> > Python still block itself from lightweight threading by keping state
>> > on the C stack".
>>
>> IMO mostly because Python wants to be friendly to extensions written
>> in C or C++, including those that frequently call back into Python.
> 
> That would only disable task-switching within the called Python code, 
> not from the code that called the extension.  And that, only if the 
> hard-switching module wasn't available.

Exactly. A tasklet can always tell whether it is on top-level, or
if there is some C code sitting on its stack. If you know that this C
code can stand a stack switch, you can switch. If not, you shouldn't
do it. This is just a little more power, to be used with care.
In Stackless 1.0, and in Python still, you simply can't do it.

But this is all irrelevant for a possible inclusion of parts of
Stackless: These would for sure avoid all hardware issues and
just do the innocent "avoid the stack" thing, raising an exception
if a switch on a C stack bound context is attempted.

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.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  mobile +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/