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: [email protected] [mailto:stackless- > [email protected]] 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: [email protected] [mailto:stackless- > >> [email protected]] 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 > >> [email protected] > >> http://www.stackless.com/mailman/listinfo/stackless > > > > > > _______________________________________________ > > Stackless mailing list > > [email protected] > > http://www.stackless.com/mailman/listinfo/stackless > > > > > _______________________________________________ > Stackless mailing list > [email protected] > http://www.stackless.com/mailman/listinfo/stackless _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
