[Python-Dev] Preventing recursion core dumps

[Vladimir Marangozov]

Just van Rossum wrote:
> 
> (Sorry for the late reply, that's what you get when you don't Cc me...)
> 
> Vladimir Marangozov wrote:
> > [Just]
> > > Gordon, how's that Stackless PEP coming along?
> > > Sorry, I couldn't resist ;-)
> >
> > Ah, in this case, we'll get a memory error after filling the whole disk
> > with frames <wink>
> 
> No matter how much we wink to each other, that was a cheap shot;

I can't say that yours was more expensive <wink>.

> especially since it isn't true: Stackless has a MAX_RECURSION_DEPTH value.
> Someone who has studied Stackless "in detail" (your words ;-) should know
> that.

As I said - it has been years ago. Where's that PEP draft?
Please stop dreaming about hostility <wink>. I am all for Stackless, but
the implementation wasn't mature enough at the time when I looked at it.
Now I hear it has evolved and does not allow graph cycles. Okay, good --
tell me more in a PEP and submit a patch.

> 
> Admittedly, that value is set way too high in the last stackless release
> (123456 ;-), but that doesn't change the principle that Stackless could
> solve the problem discussed in this thread in a reliable and portable
> manner.

Indeed, if it didn't reduce the stack dependency in a portable way, it
couldn't have carried the label "Stackless" for years. BTW, I'm more
interested in the stackless aspect than the call/cc aspect of the code.

> 
> Of course there's be work to do:
> - MAX_RECURSION_DEPTH should be changeable at runtime
> - __str__ (and a bunch of others) isn't yet stackless
> - ...

Tell me more in the PEP.

> 
> But the hardest task seems to be to get rid of the hostility and prejudices
> against Stackless :-(

Dream on <wink>.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252