Is Stackless Python DEAD?

[Cameron Laird]

In article <mailman.1009806401.11232.python-list at python.org>,
Christian Tismer  <tismer at tismer.com> wrote:
>Well, it is a little late to answer this, but...
>
>Michael Hudson wrote:
>
> > Martin von Loewis <loewis at informatik.hu-berlin.de> 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.
Cool!
			.
			.
			.
-- 

Cameron Laird <Cameron at Lairds.com>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html