Is Stackless Python DEAD?

Cameron Laird claird at
Mon Dec 31 11:17:16 EST 2001

In article <mailman.1009806401.11232.python-list at>,
Christian Tismer  <tismer at> wrote:
>Well, it is a little late to answer this, but...
>Michael Hudson wrote:
> > Martin von Loewis <loewis at> writes:
> >>- It adds a field nesting_level to the thread state, without
> >>  ever checking its value (it just counts the nesting level)
> >>
> >
> > I imagine this was just for bragging with :)
>Yes. I needed a way to track when and why there are still
>recursions. At sme pahse I also had the idea to drive
>decisions on this when I'm allowed to switch things, but
>later I learned that this is the wrong way.
Along with bragging rights, one of the not-obvious-but-
easy-to-explain reasons to introspect on recursion depth
is as a defense against denial-of-service (or more un-
intentional) security hazards.  If you're executing
something dynamic enough to give a user a wedge into the
execution stack, it's prudent, however crude it might
seem, to impose resource limits.  One engineering discovery
is that recursion depth can be a useful resource to limit.
>I'm at a redesign for Stackless 2.2. I hope to make it simpler,
>split apart Stackless and optimization, and continuations are
>no longer my primary target, but built-in microthreads.

Cameron Laird <Cameron at>

More information about the Python-list mailing list