[Stackless] Stackless 2.6.2/Win crash with very short script
Kristján Valur Jónsson
kristjan at ccpgames.com
Fri Dec 25 14:25:42 CET 2009
Hello Christian.
Nice to see you here.
No, it fell dormant and I haven't taken another look. I'll do so again, I have some time now :)
K
> -----Original Message-----
> From: Christian Tismer [mailto:tismer at stackless.com]
> Sent: 24. desember 2009 11:56
> To: Kristján Valur Jónsson
> Cc: Richard Tew; Stefan Reich; stackless at stackless.com
> Subject: Re: [Stackless] Stackless 2.6.2/Win crash with very short
> script
>
> Hi friends,
>
> was this one resolved, and the thread name chaged?
>
> cheers - chris
>
> On 8/13/09 10:51 PM, Kristján Valur Jónsson wrote:
> > I don't know. I've uncovered some nastyness in the process.
> > Soft switching is fragile with regards to channel refcounting and the
> fix I have in mind is very simple. But having it in action actually
> showed some other strange behavior that I"m looking at.
> > K
> >
> >
> >> -----Original Message-----
> >> From: Richard Tew [mailto:richard.m.tew at gmail.com]
> >> Sent: 13. ágúst 2009 20:32
> >> 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/14 Kristján Valur Jónsson<kristjan at ccpgames.com>:
> >>
> >>> I've more or less given up on this.
> >>> The problem The problem is that the engine is in a fragile state
> >>>
> >> until a soft-switch has completed. This is especially true for a
> hard-
> >> switch wrapped in a soft switch, i.e. one where a "jump_soft_to_hard
> >> has been put on the frame. Until that jump is actually performed,
> one
> >> cannot switch away from that tasklet.
> >>
> >>> In effect it means that if a stackless (or semi stackless with
> >>>
> >> jump_soft_to_hard) jump has been set up but not done, we cannot call
> >> switch tasks. And task switching occurs if a reference goes away,
> >> which is possible through multiple means in the meantime.
> >>
> >>> Maybe the best way is to put channels, wich are in such a state as
> to
> >>>
> >> require waking up a tasklet to die, in a special garbage bin, that
> is
> >> emptied in a safe place on a regular basis. I'll try that next.
> >>
> >> My worry about the potential fixes you have described for this bug,
> >> are that they are top heavy for what they are addressing. Let's be
> >> honest here, what we have is a case that crashes that no-one would
> >> ever do in production. Making larger fixes than the problem itself,
> >> well, I wonder if we are incurring additional codebase complexity
> for
> >> little benefit.
> >>
> >> I say let this one sit.
> >>
> >> Cheers,
> >> Richard.
> >>
> >
> > _______________________________________________
> > Stackless mailing list
> > Stackless at stackless.com
> > http://www.stackless.com/mailman/listinfo/stackless
> >
>
>
> --
> Christian Tismer :^)<mailto:tismer at stackless.com>
> tismerysoft GmbH : Have a break! Take a ride on
> Python's
> Johannes-Niemeyer-Weg 9A : *Starship*
> http://starship.python.net/
> 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
> work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05
> PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
> whom do you want to sponsor today? http://www.stackless.com/
>
More information about the Stackless
mailing list