External PMCs and GC Implications

[Chromatic]

Hi there,

I'm doing more work on the embedding interface. Given that some Parrot
functions may legitimately send and receive PMCs, what are the implications
for garbage collection?

I don't worry too much about the Sub and variable PMCs I get back from the
find_global*() functions, but as I'm now blessing them into Perl 5 classes, I
have the easy opportunity to use DESTROY() on them.

I know there are implications for PMCs I create myself, but it doesn't apply
here. (The external API documentation should discuss that case too though.)

-- c

[Leopold Toetsch]

Am Sonntag, 8. Oktober 2006 04:25 schrieb chromatic:
> I'm doing more work on the embedding interface.  Given that some Parrot
> functions may legitimately send and receive PMCs, what are the implications
> for garbage collection?

If a PMC isn't stored into some other structure, it has to be registered with
the extension interface function Parrot_register_pmc().

"void Parrot_register_pmc(Parrot_INTERP interpreter, Parrot_PMC pmc)"
Add a reference of the PMC to the interpreters DOD registry. This
prevents PMCs only known to extension
from getting destroyed during DOD runs.

leo