http://www.perlmonks.org?node_id=193439


in reply to On timely destruction?

Inside Out Objects, in combination with a class method that checks how many instances of an object there are:
package Test; my %attr; sub new {bless [] => shift} sub init {$attr {+shift} = undef} sub attr { my $self = shift; $attr {$self} = shift if @_; $attr {$self} } sub DESTROY { delete $attr {+shift} } sub HowMany {scalar keys %attr}
If you don't do timely destruction, HowMany will return the wrong value. This will be a disaster for programs that limit the number of instances that are allowed to be around.

However, it's not just the semantics you should worry about. Performance might depend on its as well. More than once I've written code where in the DESTROY method a file is closed (and hence, a lock on it is released). If the DESTROY no longer is timely, the semantics won't change - the program would still act correctly.

But the performance would no longer be acceptable, as other programs don't get their locks fast enough.

You can install block-exit handlers, including in your caller's block, so you don't have to play DESTROY games to get lexical exit actions.
That's nice of newly written perl6 programs. But what about perl5 programs running in a perl6 environment? Or just a perl5 module used from a perl6 program? Will they have timely DESTROY?

Allocation failure (for example running out of filehandles) will trigger a GC sweep and retry of the failing operation, so your program won't run out of things for lack of timely cleanup.
Could you elaborate on that? If program1 (not necessarely written in Perl) has an allocation failure because program2 (written in Perl) hasn't done a GC sweep yet, how's that going to trigger a GC sweep in program2?

I'm more concerned about the overal impact on the system a perl6 program is going to run on then the impact on the program itself.

Java's unpredictable GC is already giving lots of people a headache when dealing with long running Java programs. It would be a pity if Perl goes that way too.

Abigail