[Stackless] I need Input (was: Stackless breaks generators that do not yield)
sune at mel.interspace.dk
Wed Mar 19 21:18:47 CET 2003
[ Christian Tismer ]
[ Big Snip(tm) ]
> In 3,0 that is, the tasklets will no longer be created
> by some magic, but a special frame will be created and pushed
> that is able to run a tasklet. Frame chains will no longer
> be disjoint, ended by NULL, but they will all end up in
> one special frame which a special f-execute that redirects
> all returns to the one main tasklet. And so on.
> So the concept is to do the complete callback game, and
> only to switch C stacks if it is unavoidable.
This sound like a nice, clean way to do things.
> The decision about "who onws the frame" is harder than
> I thought, sine it has to be complete:
> Either, the frame is always self-owned, or it is never.
> Reason? If a frame may destruct itself, a calling function
> can never inspect it and expect a proper frame, unless
> it puts extra references, which I hate.
> Or, a frame may never destruct itself, unless it is done
> in a simple recursive function call context; compare the
> special frame handling in pyexpat.c.
> In the second case, a returning, finished frame would
> always set the flags.done flag in order to get destroyed.
If I understand this correctly function-call/return would work much
the same as it does now, with the caller being deactivated (via
unwinding) at call-time and reactivated again when the callee
If so, I think I would let the caller decref the callee-frame when
the caller is being reactivated (and after it has done any
inspection it needs to do). To me caller-decrefs seems the simpler
semantic of the two.
(One example where I think suicidal frames are troublesome are with
generators: if a generator is destroyed before it's frame is done,
gen_dealloc will have to decref the frame twice to make up for the
frames self-reference (what my first generator-patch did). That has
a slightly fishy smell to me. . .)
Sune Kirkeby | With sufficient thrust, pigs fly just fine.
| -- RFC 1925
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 1772 bytes
Desc: not available
More information about the Stackless