in reply to Object reference disappearing during global destruction

It's like some invisible hand reaches into the system between two of the many, many DESTROY calls, and yanks out that (and only that) reference.

Yep. Unfortunately, global destruction is a free-for-all, and you can't count on any sane order of destruction. Perhaps the best option you have is to add an explicit non-DESTROY destructor called manually. (If you're clever, tie it to one of the end-of-scope-action modules on the CPAN, pun intended.)

Reference counting is all well and good, but at the end of the interpreter, Perl yells "Everybody out of the pool!" and occasionally someone'll leave his little locker key behind in the ensuing madness.

  • Comment on Re: Object reference disappearing during global destruction

Replies are listed 'Best First'.
Re: Re: Object reference disappearing during global destruction
by khkramer (Scribe) on May 15, 2002 at 19:24 UTC

    But the interpreter isn't cleaning up the object, it's setting the reference to undef. The object is still around (and accessible by other means).

    I like your recreational-swim analogy, but I'm still trying to figure out how the behavior I'm seeing is consistent with the specified operation of the garbage collector. The Camel book says that objects are always destroyed in a separate pass before ordinary references (3rd ed. page 331), and maybe that's a clue, but there's still a problem:

    When the interpreter is ready to exit, presumably "everything" goes out of scope. At that point, there are no references left to my $::index object. So it should be garbage collected pretty early. But it's not and, worse, an object reference it's holding is set to undef at some apparently arbritrary moment. I've been very careful to avoid circular references, so there *is* a sensible destruction order for these objects. But if references disappear without provocation, then that order can't be maintained.

[reply]
      Maybe Elian will correct me if I'm completely wrong here, but reference counting isn't all that useful during global destruction. First, how do you figure out which items to collect first? Second, how do you deal with circular references? Third, if everything's going to be cleaned up anyway, does it matter? Fourth, it takes a lot longer to come up with a grand master plan than it does to pick a corner of the pool and start sweeping.

      As much as I'd like to believe that you can count on objects being destroyed, during global destruction, in normal, reference-counted order, I've never seen it happen. When it's mattered, I've always had to start the chain reaction myself.

[reply]

      Let me give it a shot.

      First off, let me make sure I understand. You have a reference to an object, and you are dereferencing that ref in print statements, wondering whats going on, right?

      If you have a reference to an object, then the destruction of that reference will not invoke a call to a DESTROY method, only the objects actual destruction will. The objects destruction will occur in a pass before destruction of anything else. If you have a reference to an object, and the object is destroyed first (which it should be) the the reference points to nothing - undef. If the the scalar holding the reference to the object is itself undefed, and the object still exists, then this may be inconsistent with Perl's two pass out-of-the-pool system (where objects go first, so that their DESTROY methods can safely operate on variables in the environment). But, if you simply have a reference to the object, and you dereference that reference, then it should come up undef after global object destruction and before destruction of everything else.

      Hope that helps.

      Cheers,
      Erik

      Update: I just realized this is my 100th post. Yay!

[reply]

In Section Seekers of Perl Wisdom