Right, so we really have two options: 1) We have a "timely" destruction, which isn't timely and isn't predictable or useful 2) We explicitly kill PMCs when we want them dead, and risk keeping references around for later.
A third option would be to VTABLE_destroy the PMC and morph it into a Null PMC in-place. Anybody still referencing it will get a Null PMC exception, but won't crash. We still get freed resources, just not freed PMC headers. The PMC_IS_NULL macro would have to grow a little, of course. --Andrew Whitworth On Wed, Sep 22, 2010 at 8:36 PM, Vasily Chekalkin <[email protected]> wrote: > Hello. > > On Thu, Sep 23, 2010 at 10:31 AM, Andrew Whitworth > <[email protected]> wrote: >> Changing our mechanism for timely destruction would be good. I've >> always thought it felt a little flimsy. I'm not sure what we want to >> replace it with. Maybe a "destroy_and_null" opcode, which would >> destroy the PMC and null the contents of the register to prevent >> accidental reuse. Or, we can attach PMCs needing timely destruction to >> a context or Sub, and when the Context/Sub exits, we destroy all the >> attached "eager" PMCs. > > In CPS VM there is no difference between "call" and "return". However > we have explicit C<returncc> so we can attach "list of pmcs to > destroy" to CURRENT_CONTEXT and implicitly destroy them. Only one > problem - if someone attach "live" PMC from outer context to "destroy > list" we will crash. Epically. > > -- > Bacek > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
