[Stackless] Stackless 2.6.2/Win crash with very short script

[Richard Tew]

And my suspicion is that we changed something to do with nesting
levels which fixed something else, and broke this by causing the soft
switch instead of the a hard one.

2009/8/10 Richard Tew <richard.m.tew at gmail.com>:
> Sorry, by frame going away, I meant the exiting of the function call
> which frees its locals including the channel.
>
> 2009/8/9 Kristján Valur Jónsson <kristjan at ccpgames.com>:
>> Richard, I don't think this is it at all.  Blocking doesn't cause the frame to go away, and the frame doesn't get collected before the error occurrs.
>> I think it is a simple malfunction in the soft-switching code.  The issue goes away if soft-switching is turned off.
>> I'll have another go at it.
>>
>>> -----Original Message-----
>>> From: Richard Tew [mailto:richard.m.tew at gmail.com]
>>> Sent: 9. ágúst 2009 04:42
>>> To: Kristján Valur Jónsson
>>> Cc: Stefan Reich; stackless at stackless.com
>>> Subject: Re: [Stackless] Stackless 2.6.2/Win crash with very short
>>> script
>>>
>>> 2009/8/8 Kristján Valur Jónsson <kristjan at ccpgames.com>:
>>> > I had a go at this today.
>>> > It is a bug with soft-switching.  turning off soft switching makes
>>> the problem go away.
>>> > The issue happens when the tasklet blocks and the sheduler is
>>> reviving main.  It decides to try soft switching but then inserts the
>>> hard switching frame.  This is how far I got.
>>> >
>>> > Richard, I am very unfamiliar with soft switching so maybe you can
>>> help me out with this in a private thread?
>>>
>>> This is the old problem I fixed years ago approaching from a different
>>> angle.  It looks like some other change we have made has broken it in
>>> a different way.  We should be hesitant we don't break something else
>>> when we fix this.
>>>
>>> I don't have time to look further into this right now, especially
>>> given that it is not a realistic use case that someone would encounter
>>> in a deployed application.
>>>
>>> But my understanding of it is that a tasklet blocks on a channel that
>>> was created within it.  This soft switches and the tasklet function
>>> exits, causing garbage collection of the channel (because tasklets do
>>> not hold references to channels they block on and the only reference
>>> to the channel is the frame).  The garbage collection of the channel
>>> with the only reference to the tasklet within it, means the tasklet is
>>> also garbage collected.  So of course we hard switch to the tasklet,
>>> despite the fact we are still effectively in it.
>>>
>>> I don't see an obvious fix to this.
>>>
>>> Cheers,
>>> Richard.
>>
>>
>