in reply to Destructor Order

There is no easy way to guarantee that the COM port object is still there when you destroy the Reader object if the destruction happens during global destruction (which it sounds like it may be in your case). The reason is that global destruction goes by force, and nobody is safe (necessary to be sure that circular references get cleaned up). I believe that 5.8 has a hack to make sure that things often get cleaned up in a convenient order, but there are cases where that fails.

Instead arrange to have the object cleaned up in an END block. END blocks are processed before global destruction, and so you can safely rely on things that you expect to still find alive, not being destroyed out of order.

Replies are listed 'Best First'.
Re: Re: Destructor Order
by sgifford (Prior) on Apr 03, 2004 at 07:48 UTC

    Yes, the problem is happening during global destruction.

    I tried an END block, and it works, with some caveats. It seems END blocks don't fire if the script exits from an uncaught signal, which is how the script is exiting, at least while I'm testing. Adding signal handlers that just call exit(1) seems to work fine, though, although it feels kludgey.

    Thanks!

[reply]
[d/l]
[select]
      Just switching to use lexicals instead of package variables should avoid global destruction and let your objects be destroyed as their refcounts dictate, e.g.: 
      $ perl -w
sub DESTROY { warn $_[0]->{name} }
my $inner = bless {name => "inner"};
my $outer = bless {name => "outer", inner => $inner};
__END__
outer at - line 1.
inner at - line 1.

      [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom