[Stackless] stackess for 2.7

Jeff Senn 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!

Yay!

> 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!

> 
> 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
> 
> 
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless
> 




More information about the Stackless mailing list