ordered destruction

[allison]

Extend or modify the existing GC and GC modules to allow ordered destruction (guarantee that the children of one PMC will all be destroyed before that PMC, etc).

[chromatic]

Note that dynpmcs with destroy() must be destroyed before the ParrotLibrary PMCs which represent their shared libraries (RT #46761).

[dukeleto]

Just wanted to note that this issue causes nt/exit.t to coredump in Blikzkost's test suite. sorear++ and NotFound++ describe the issue in #parrot on 8.Sept.2010 :

<@sorear> dukeleto: Parrot has no concept of ordering in global destruction
<@sorear> dukeleto: blizkost SV proxies need to drop Perl-side references when destroyed
<@sorear> dukeleto: that means 1. blizkost needs to still be loaded 2. the Perl interpreter needs to still exist
<@NotFound> dukeleto: I suppose the problem is that it tries to destroy the sub that is calling exit.

[jkeenan]

Milestone 3.6 deleted

[jkeenan]

Can anyone an update on the status of this ticket?

Thank you very much.

kid51

[bacek]

Hello.

I would like to close this bug as "wontfix". GCable objects can't be represented as acyclic graph in general case. So "children" of "some PMC" can be actually "parent" of same PMC. We do need different mechanism to support such behavior. E.g. "finalize"/"dispose" from JVM/CLR world.

-- Bacek