Ticket #607 (new roadmap)

Opened 5 years ago

Last modified 3 years ago

ordered destruction

Reported by: allison Owned by:
Priority: major Milestone: 2.11
Component: GC Version:
Severity: medium Keywords:
Cc: Language:
Patch status: Platform: all

Description

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).

Change History

Changed 5 years ago by chromatic

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

Changed 4 years ago by dukeleto

  • priority changed from normal to major
  • platform set to all
  • component changed from none to GC

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.

Changed 4 years ago by jkeenan

  • milestone 3.6 deleted

Milestone 3.6 deleted

Changed 3 years ago by jkeenan

  • milestone set to 2.11

Can anyone an update on the status of this ticket?

Thank you very much.

kid51

Changed 3 years ago by 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

Note: See TracTickets for help on using tickets.