At 2:17 PM -0400 6/1/02, Melvin Smith wrote:
>Now there are a dozen ways to handle this. Using flags, keeping args on the
>stack until return, yada yada yada...
>
>I'd like to hear suggestions, or maybe reference to past discussions I might
>have missed on how we shall handle this. Actually I want more than
>suggestions,
>I want a voice from the sky to boom, "Go that way!"
Here's what I've been thinking about for extensions, since there are
a number of GC issues.
Parrot-aware functions get called like parrot subs. If they clean
things out, too bad for them.
Non-parrot-aware functions will be wrapped, and the wrapping
functions won't clear anything out, which is fine.
The interesting bit comes in when we actually allocate stuff. For
that... What I'm pondering is that we put a stack mark somewhere, and
the new_pmc/new_string/new_buffer functions for extensions not only
allocate their particular thing, but *also* push it onto the stack.
That'll keep things on the root set appropriately, and we'll clean
off the extra stack drek when we exit, so things'll get GC'd if they
need to be.
Since extensions are supposed to be isolated from the interpreter
internals, I'm just fine with them not knowing about stacks,
registers, and suchlike things. We can work some thunking magic here
to make it work out. Yeah, it'll be a little slower, but that's fine.
If people want fast they can write opcode functions and have to deal
with all the gory details themselves.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
Perl class: stemsystems.com/class teddy bears get drunk
