[Stackless] I need Input (was: Stackless breaks generators that do not yield)

Christian Tismer tismer at tismer.com
Mon Mar 17 14:28:46 CET 2003


Sune Kirkeby wrote:
[...]

> I think I have found the problem wrt generators. What happens is
> that slp_dispath_frame Py_DECREFs frames when they are done, but
> in some instances (when the generator does not yield, I suspect)
> the frame has already been garbage-collected. Needless to say this
> makes things go spectacularly bad from time to time.
> 
> I solved the problem by Py_INCREFing the frame in gen_new and
> Py_DECREFfing it in gen_dealloc, but only if the frame is not done,
> when it is done slp_dispatch_frame will have Py_DECREFfed it
> already.

Thanks a lot for the patch, which works fine.

I already thought of something similar, but
was unhappy with my solution of frame disposal
at all.
The problem is this:
In the unpatched original Python, frame disposal
is handled this way:
PyEval_EvalCodeEx creates a frame, executes it
and disposes it.
gen_new creates a new frame, attached to a generator
object.
gen_iternext runs this frame until it returns.
Only the generator destructor disposes the frame.

So, in a sense, the "caller" is always responsible
to clean up the frame it created.

In Stackless, I don't have this concept at the moment,
there is no such thing as a "caller" when the dispatcher
plays its game. That made me invent these nasty flags
which signal whether a frame is done. This isn't
very natural and needs to be either special cased
for generators, or the refcount must be bumped,
like in your patch.

For the moment, I took your patch, many thanks.

Later, I think to go one of these paths:
a refine the extra flags, such that generator
   frames are never decreffed but by the gen object
b remove the decreffing code from frame_dispatch
   and revert the policy to "a frame has to take
   care for itself", while keeping generators untouched
c replace the missing concept of callers by tiny
   extra frames, which take care of frame deallocation.
d ??? other ideas ???

c seems to be quite a clean solution, but maybe the
   extra effort to put extra frames on the stack
   might be a bit much?

I'm not sure which path to follow.
Can a few people please let me know their opinion?

thanks -- chris

-- 
Christian Tismer             :^)   <mailto:tismer at tismer.com>
Mission Impossible 5oftware  :     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 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/

_______________________________________________
Stackless mailing list
Stackless at www.tismer.com
http://www.tismer.com/mailman/listinfo/stackless




More information about the Stackless mailing list