[Stackless] Re: [Python-Dev] Stackless pages

est at hyperreal.org est at hyperreal.org
Mon Nov 6 05:39:29 CET 2000


Jeremy Hylton discourseth:
> 
> The sort of implementation complexity that I worry about with
> Stackless is, e.g. clean interaction with the C stack.  If a Python C
> API call is made that pushes a C stack frame, e.g. PyObject_Compare,
> then a continuation stored before that call can no longer be invokved.
> The problem is that continuations break the notion a C API call will
> always return an answer; they create a situation in which the C call
> that is made should never return, because control is transferred to
> the continuation.  I assume Stackless raises an error in this case,
> but this seems pretty messy: How do we right a language spec that
> explains when an error will occur without appealing to the
> language implementation?

This point is particularly worrisome to me because of a common pattern
I see in my own Python development work.  I'll define a class which is
parameterized with some callbacks.  Sometimes, when profiling reveals
the need, I'll move these classes to C.  If the client of the class is
using continuations via its callbacks, it may suddenly break.  This
seems a step back in the modularity I can count on in my program
components.

..and I say this as a long-time, die-hard Schemer. :)

I definitely pine for micro-threads in some of my application domains
though.

Eric
_______________________________________________
Stackless mailing list
Stackless at starship.python.net
http://starship.python.net/mailman/listinfo/stackless



More information about the Stackless mailing list