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

[Kristján Valur Jónsson]

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.

K


> -----Original Message-----
> From: Kristján Valur Jónsson
> Sent: 11. ágúst 2009 14:40
> To: Kristján Valur Jónsson; Richard Tew
> Cc: Stefan Reich; stackless at stackless.com
> Subject: RE: [Stackless] Stackless 2.6.2/Win crash with very short
> script
> 
> Ok, I know what the problem is.  I'm also working on a fix.
> The problem is this:
> The tasklet is softswitched out in channel().receive().
> The callstack is:
> 	python27_d.dll!channel_receive(_object * self=0x025e6470)  Line
> 629 + 0x9 bytes	C
>  	python27_d.dll!call_function(_object * * * pp_stack=0x0026b468,
> int oparg=39740528)  Line 3980 + 0xc7 bytes	C
>  	python27_d.dll!PyEval_EvalFrame_value(_frame * f=0x02462ea8, int
> throwflag=0, _object * retval=0x1e2e4cc8)  Line 2581	C
> 
> Now, the softswitch is not _really_ complete until we have returned to
> PyEval_EvalFrame_value(), because until then, the old frame's
> f_stacktop==NULL.
> But, during the stack cleanup in call_function, this hasn't happened
> yet, and this is where the channel gets destructed and it tries to
> awaken the old task.
> 
> My fix is to save the f_stacktop early in call_funtion before the
> cleanup, and this avoids the issue, but I have stumbled upon another.
> K
> 
> > -----Original Message-----
> > From: Kristján Valur Jónsson
> > Sent: 10. ágúst 2009 16:34
> > To: Kristján Valur Jónsson; Richard Tew
> > Cc: Stefan Reich; stackless at stackless.com
> > Subject: RE: [Stackless] Stackless 2.6.2/Win crash with very short
> > script
> >
> > Here is the problem:
> > 1) we set up for softswithing from the tasklet, by setting up this
> > "soft_to_hard" frame.  Which will hardswitch later.
> > 2) receive() returns, propmting deletion of the temporary channel
> > object
> > 3) channel is deleted, but there is a blocked tasklet there, so it
> > needs waking up
> > 4) A hard switch is made into that tasklet.  But something goes wrong
> > now.
> >
> > I spent the afternoon revisiting the theory of hardswitching and
> > softswitching.
> > Basically, softswitching is only possible if both target and and
> source
> > tasklets have nesting level 0.  But one can always hardswitch.
> >
> > One thing I don't understand, is why there is the "jump_soft_to_hard"
> > callback?  It should be possible just to decide to use hardswitch
> > instead of piggibacking the hardswitch onto the softswitching
> > mechanism.  Or is it to avoid saving the satck for the source tasklet
> > and unroll its nesting level back?  Hm, probably.
> >
> > Anyway, I'll try to find out what's wrong.
> >
> > K