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:[email protected]]
> Sent: 9. ágúst 2009 04:42
> To: Kristján Valur Jónsson
> Cc: Stefan Reich; [email protected]
> Subject: Re: [Stackless] Stackless 2.6.2/Win crash with very short
> script
> 
> 2009/8/8 Kristján Valur Jónsson <[email protected]>:
> > 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.


_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless

Reply via email to