[Stackless] stackess for 2.7

Kristján Valur Jónsson kristjan at ccpgames.com
Mon Jul 5 22:56:13 CEST 2010


I've integrated the last changes from /python/trunk and we now have a /stackless/trunk that jives with 2.7 release!
I didn't have any trouble to speak of with the 64 bit build, and I fixed the test_sys.py test that was failing there.
In my opinion, stackless/2.7 is pretty good!

I am still working on some old time issues with garbage collection.  stackless/test/taskspeed.py crashes in debug mode and this is because of GC.  I've made progress, but it needs to be perfected.  Basically, what I aim to do is to allow tasklets that have no c state to be collectable from gc, without awakening them (killing the tasklet).  Such a tasklet ought to be just collected.  Tasklets that have C state must be killed (awakened and unrolled) and this must happen after they have been placed in gc.garbage.  I've added features to gcmodule.c so that objects can indicate at run-time whether they can be collected or not.  I've even contributed that patch to vanilla Python (http://bugs.python.org/issue9141) but without it meeting much enthusiasm.

K

> -----Original Message-----
> From: stackless-bounces at stackless.com [mailto:stackless-
> bounces at stackless.com] On Behalf Of Jeff Senn
> Sent: 5. júlí 2010 02:46
> To: The Stackless Python Mailing List
> Subject: Re: [Stackless] stackess for 2.7
> 
> Ok - sounds fine.
> 
> More generally my 64 bit build also crashes on many of the stackless
> tests - so I suspect a general problem
> as well (possibly a platform specific one -- as they are generally,
> slightly post stack swap).
> 
> I don't really rely on a 64 bit build at the moment for my work (since
> I have other dependencies that
> keep me at 32) -- is the amd64 build supposed to work?
> 
> On Jul 3, 2010, at 5:18 AM, Kristján Valur Jónsson wrote:
> 
> > You are right.
> > This is not a new problem, though.
> > In our working branch at CCP, we have this particular test disabled
> for this reason.
> > It could be an idea to add the python recursion guard calls even to
> safe-pickle.
> >
> > Btw, I'm not sure why Christian deemed pickling to be enough of a
> special case to warrant special pickling code with stack-spilling.
> > Perhaps pickling tasklet regularly caused such deep recursions that
> this was necessary.  If that is the case, then we shoulnd't
> > impose artificial recursion limits...
> >
> > I think we ought to leave this as an open issue in the "stackless
> defect tracking database in the sky" :)
> > K
> >
> >> -----Original Message-----
> >> From: stackless-bounces at stackless.com [mailto:stackless-
> >> bounces at stackless.com] On Behalf Of Jeff Senn
> >> Sent: 1. júlí 2010 18:08
> >> To: The Stackless Python Mailing List
> >> Subject: Re: [Stackless] stackess for 2.7
> >>
> >>
> >> On Jul 1, 2010, at 12:08 PM, Jeff Senn wrote:
> >>
> >>> Speaking of 64bit... are you compiling a 64bit version? I am having
> >> some trouble...
> >>> In particular test_cpickle crashes (segfault) in  test_issue2702
> >> (__main__.cPickleDeepRecursive)
> >>
> >> Update on this:
> >>
> >> Note the test (an attempt to pickle a deeply nested unrealistic
> object)
> >> is designed to fail due to excessive recursion.
> >>
> >> It appears that in 64-bit mode this test only survives down to a
> >> recursion limit of about 273 (note: < 1000) before things go
> horribly
> >> wrong -- I'm guessing that the greater stack requirements of 64 bit
> >> simply cause a problem (compared to the 32-bit version) and the
> >> simplest solution is just to reduce the recursion limit for that
> >> build... (It's hard to determine the "final cause" of the crash as
> the
> >> debugger is messed up when I get there... probably crunching the
> stack?
> >> dunno...)
> >>
> >> However (caveat: as I said the pickling part of stackless is not my
> >> favorite...) it seems like the stackless bit that avoids the call to
> >> Py_EnterRecursiveCall in cPickle.c, and instead uses
> slp_safe_pickling,
> >> is sort of asking for trouble in this case.
> >>
> >> In this test (in non-stackless python), the excessive recursion of
> the
> >> cPickle module itself (calling 'save') is detected by the
> >> Py_EnterRecursiveCall check.  In stackless (I think) this test is
> >> bypassed (due to the unwind of pickling) and the recursion count
> grows
> >> significantly more slowly (and only incidentally due to a deeper
> call
> >> to Py_CallObject.)
> >>
> >> I'm not sure if there is a simple and satisfying fix...
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Stackless mailing list
> >> Stackless at stackless.com
> >> http://www.stackless.com/mailman/listinfo/stackless
> >
> >
> > _______________________________________________
> > Stackless mailing list
> > Stackless at stackless.com
> > http://www.stackless.com/mailman/listinfo/stackless
> >
> 
> 
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless




More information about the Stackless mailing list