[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