Um, all instances of perl under Unix are instantiated using exec(). DESTROY doesn't get called if you script goes away because of a successful exec. How perl was started doesn't matter.

Now, if the script isn't being run by perl (the separate executable) but is instead being run by a Perl interpretter embedded in some other executable, then your object might not be destroyed until the interpretter is torn down, and that might not happen until much later in such cases. mod_perl is just one example of this. You can usually check $^X to if you have such a case.

If you avoid putting references to your object into global variables (also known as package variables), then your DESTROY method won't have to wait until the interpretter is destroyed. But inheritting from CGI would probably break that since CGI stores a reference to its first instantiation into a global variable in case you use the "function" interface (vs. of the OO interface).

>Um, all instances of perl under Unix are instantiated
>using exec(). DESTROY doesn't get called if you script
>goes away because of a successful exec. How perl was
>started doesn't matter.
That is not completely true. If you'd do `exec perl -e 'print "hello world\"'` on your shell, then the shell will be thrown away and be replaced with the perl interpreter. It wont return either...

Sinister greetings.
"With tying hashes you can do everything God and Larry have forbidden" -- Johan Vromans - YAPC::Europe 2001
perldoc -q $_

But that doesn't change whether DESTROY is called:

 $ perl -e "sub DESTROY{warn'dead'}\$x=bless{};"
dead during global destruction.
 $ exec perl -e "sub DESTROY{warn'dead'}\$x=bless{};"
dead during global destruction.
[download]

BTW, in both of the cases above, perl is launched by using exec() [the subroutine from the C run-time library that wraps the kernel hook (or "system call")]. The difference is that the shell's "exec" command avoids the fork() before the exec().

        - tye (but my friends call me "Tye")