[Stackless] stackess for 2.7
senn at maya.com
Tue Jul 6 02:58:35 CEST 2010
On Jul 5, 2010, at 4:56 PM, Kristján Valur Jónsson wrote:
> 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.
But that is probably an x64_msvc build (rather than amd64_unix), right?
I notice whoever built 2.6.5 stackless for OS-X (not me I think) did not include a 64-bit variant in the universal binary...
I'm just wondering whether amd64 is supposed to work.. (I just went back and the release26-maint branch also has problems with 64 bit on OS-X -- so at least it's not a merely 2.7 issue...)
> 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.
FWIW - sounds good to me!
>> -----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
>>> 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" :)
>>>> -----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
>>>> Update on this:
>>>> Note the test (an attempt to pickle a deeply nested unrealistic
>>>> 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
>>>> 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
>>>> debugger is messed up when I get there... probably crunching the
>>>> 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
>>>> is sort of asking for trouble in this case.
>>>> In this test (in non-stackless python), the excessive recursion of
>>>> 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
>>>> significantly more slowly (and only incidentally due to a deeper
>>>> to Py_CallObject.)
>>>> I'm not sure if there is a simple and satisfying fix...
>>>> Stackless mailing list
>>>> Stackless at stackless.com
>>> Stackless mailing list
>>> Stackless at stackless.com
>> Stackless mailing list
>> Stackless at stackless.com
> Stackless mailing list
> Stackless at stackless.com
More information about the Stackless