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

[Sune Kirkeby]

[ 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
returns?

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
Type: application/pgp-signature
Size: 1772 bytes
Desc: not available
URL: <http://www.stackless.com/pipermail/stackless/attachments/20030319/cb159ab7/attachment.pgp>