Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

External PMCs and GC Implications

4 views
Skip to first unread message

Chromatic

unread,
Oct 7, 2006, 10:25:18 PM10/7/06
to parrot-...@perl.org
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

unread,
Oct 8, 2006, 7:17:23 AM10/8/06
to perl6-i...@perl.org
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

0 new messages