perplexing DESTROY behavior 
Author Message
 perplexing DESTROY behavior

I've gotten some answers since I first posted this. It seems that
globals aren't destroyed in any particular order. Since my object
contains other IO::Handle objects, they are obviously getting
destroyed before my destroy method gets called. While I can verify
that this is true, I don't fully understand this behavior.

I could understand if I created multiple global objects that they
would be destroyed in a (seemingly) random order. But the object I
create has these IO::Handle objects embedded in it. Why would Perl
choose to destroy the embedded object before it destroyed the parent
object? Isn't the reference count to those embedded objects non-zero?

Jeff

Quote:

> I've written a module that, on construction, forks and execs a child
> which it will communicate with over it's lifetime. Instead of forcing
> my module's users to explicitly shutdown the child, I wanted to do in
> the DESTROY method, the perfect place. The problem is, I'm seeing some
> weird behavior: in many situations, the child process has already died
> by the time the object's DESTROY method is called.

> I've run lots of little experiments and determined that it's dependent
> on the type of variable that the Module user used to create the object.

> The two options are global and lexical. Lexical does the right thing
> almost all the time. Globals never seem to do the right thing. When I
> say "right thing", I mean that when I get to the object's DESTROY
> method, I either already find the child process dead or alive. If it's
> alive, I consider that the "right thing".

> With lexicals, this works:

>     my $o = Mymod->new;
>     foo($o);
>     exit;

>     sub foo {
>    my $o = shift;

>    $o->method;
>     }

> But this doesn't:

>     my $o = Mymod->new;
>     foo();
>     exit;

>     sub foo {
>       $o->method;
>     }

> I dont' understand why the second way fails. $o is a lexical at the
> top level. Why does accessing it from with a sub cause it to be
> treated in a way that kills the child before $o's DESTROY method is
> called?

> I always get the incorrect behavior if I declare $o in this way:

>     use vars qw($o);

>     $o = Mymod->new;

> The only way to get the correct behavior is to do the following before
> I exit:

>     undef $o

> or

>     END {
>    undef $o
>     }

> which really isn't surprising since I'm just explicitly calling the
> DESTROY method. This also defeats the purpose of having the DESTROY
> method in the first place, since the whole point was for object
> destruction to be implicit. These examples also cause the failed
> lexical attempt from above to work correctly which again isn't
> surprising for the same reason.



Tue, 06 Nov 2001 03:00:00 GMT  
 perplexing DESTROY behavior

Quote:

> globals aren't destroyed in any particular order. Since my object
> contains other IO::Handle objects, they are obviously getting
> destroyed before my destroy method gets called. While I can verify
> I could understand if I created multiple global objects that they
> would be destroyed in a (seemingly) random order. But the object I
> create has these IO::Handle objects embedded in it. Why would Perl
> choose to destroy the embedded object before it destroyed the parent
> object? Isn't the reference count to those embedded objects non-zero?

Jeff,

I had this exact problem recently, and while it spawned quite a technical
debate, I never got a satisfactory answer to the question you just asked.
You might want to check out the thread "Perl DESTROY sequence at termination"
in DejaNews:

http://www.deja.com/getdoc.xp?AN=459064529

It seems to be a rather large deficiency in the way the garbage collector
works at shutdown.

--

Geek Code: GCS d? s: a- C++ US++++$ P+++ L+ w PS+ 5++ b++ DI+ D++ e++ r++ y+*
  "I want to take over the world because I'm an egomaniac."  --Larry Wall



Sat, 10 Nov 2001 03:00:00 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. perplexing DESTROY behavior

2. Strange Behavior with DESTROY methods and $SIG{__die__} Handlers

3. Strange behavior with DESTROY and END

4. Strange Behavior with DESTROY methods and $SIG{__die__} Handlers

5. DESTROY not destroying

6. Puzzle: DESTROY not destroying

7. destroy and DESTROY in Tk/Perl

8. ? Now I am reaaly perplexed, Why doesn't (INDEX) work

9. Perplexing problem

10. Perplexed: Can't modify non-lvalue subroutine call

11. Perplexed....

12. perplexing print problem

 

 
Powered by phpBB® Forum Software