lisch@mentor.com (Ray Lischner) (11/09/90)
After thinking about the problem a little, I decided I prefer
a different way of having cleanup handlers. I suggest there be
an array, @EXIT. The user adds subroutine names to @EXIT.
Before exiting, Perl goes through @EXIT, in order, and calls
each subroutine with no arguments. An @EXIT handler is not
allowed to modify @EXIT, and the exit and die operations are
ignored inside an @EXIT subroutine.
The user can control the order of the cleanup handlers, usually
by appending to @EXIT with push, or inserting a handler at the
beginning of the list, with unshift. A package can add a cleanup
handler without bothering the user of the package with such details.
For example:
package number1;
sub cleanup
{
unlink($lock_file);
}
push(@EXIT, "number1'cleanup");
package curses;
&initscr;
sub cleanup
{
&endwin;
}
push(@EXIT), "curses'cleanup");
--
Ray Lischner UUCP: {uunet,apollo,decwrl}!mntgfx!lischcarl@udwarf.tymnet.com (Carl Baltrunas & Cherie Marinelli 0.1.9) (11/12/90)
In article <1990Nov9.005202.18300@mentor.com>, lisch@mentor.com (Ray Lischner) writes: > > After thinking about the problem a little, I decided I prefer > a different way of having cleanup handlers. I suggest there be > an array, @EXIT. The user adds subroutine names to @EXIT. > Before exiting, Perl goes through @EXIT, in order, and calls > each subroutine with no arguments. > Don't flame me... I'm not familiar with atexit, nor much more than an apprentice with using perl, but I've used other languages that allow for cleanup and there are a few comments I'd like to make about this post. I think the user need not be aware of the "mechanism" of how the cleanup routines are invoked. Knowing it's an array is nice (to examine, but never never touch). A "better" way is to allow a user to specify cleanup routines for the main, and for any called procedures. When a cleanup routine is set up, it gets invoked regardless of error conditions. That's why it's a clean- up routine (you don't want to clean up everwhere a routine or procedure might exit, successful or unsuccessful). > An @EXIT handler is not > allowed to modify @EXIT, and the exit and die operations are > ignored inside an @EXIT subroutine. The exit and die operations SHOULD definately be valid inside a cleanup proc. But, you should not ever need to add/delete cleanup procedures while you're in the process of cleaning up. > > The user can control the order of the cleanup handlers, usually > by appending to @EXIT with push, or inserting a handler at the > beginning of the list, with unshift. Yes, this is needed.... but (again, not with a push as mentioned below) > A package can add a cleanup > handler without bothering the user of the package with such details. > Modified with my "better suggestion" (please ignore perl syntax violations) > For example: > package number1; cleanup clean1 { unlink($lock_file); } sub routine_name { any code you like here clean1 will be called to cleanup however this process exits and will be transparent, so any returned values will remain intact. clean1 should not be able to modify the return value. } > -- > Ray Lischner UUCP: {uunet,apollo,decwrl}!mntgfx!lisch > I'm also for initialization routines that get run before procedures (including your main program. For more info, e-Mail me, or find a copy of the manual for SAIL (an algol baseed language developed at Stanford AI Lab for the PDP-10s) to see it's use of initialization and cleanup routines. -Carl Carl A Baltrunas - Catalyst Art Cherie Marinelli - Bijoux {sumex, apple}!oliveb!tymix!atlas!udwarf!{carl or cherie} {carl or cherie}%udwarf@tardis.tymnet.com