AtExit

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

    - Added COPYRIGHT AND LICENSE section to pod
    - Added this Changes file
    - Added "use warnings"

2.01 1999-01-20 BRADAPP
    - rmexit may now be called (as a function or a method) with *no* arguments.
      When this happens, *all* exit-handlers are removed!

2.00 1998-10-20 @bradapp
    - Made the following changes based on patches contributed by Michael Chase
    - AtExit may now be used as a class to create objects which invoke callbacks
      whenever the AtExit object is destroyed (or goes out of scope with no
      other references to it).
    - atexit() amd rmexit() may now be invoked as functions, or as methods.
      When invoked as methods, they operate on an object for destruction-time
      callbacks. Otherwise they operate on the program for program-exit-time
      callbacks.
    - Added the exit_subs(), is_exiting() and ignore_when_exiting() subroutines
      to replace the use of @AtExit::EXIT_SUBS, $AtExit::EXITING, and
      $AtExit::IGNORE_WHEN_EXITING. Use of these three variables is now
      deprecated in favor of these new subroutines.
      Although atexit & rmexit are still exported (for backward compatibility),
      exit_subs(), is_exiting() and ignore_when_exiting() are NOT exported
      by default.
    - $AtExit::EXITING, $AtExit::IGNORE_WHEN_EXITING, and @AtExit::EXIT_SUBS
      are now merely aliases to a class hash/object.

lib/AtExit.pm  view on Meta::CPAN

the C<atexit> function in the standard C library (see L<atexit(3C)>).
Various exit processing routines may be registered by calling
B<atexit> and passing it the desired subroutine along with any
desired arguments. Then, at program-exit time, the subroutines registered
with B<atexit> are invoked with their given arguments in the
I<reverse> order of registration (last one registered is invoked first).
Registering the same subroutine more than once will cause that subroutine
to be invoked once for each registration.

An B<AtExit> object can be created in any scope. When invoked as a
function, B<atexit> registers callbacks to be
executed at I<program-exit> time. But when invoked as an object-method
(using the C<$object-E<gt>method_name> syntax),
callbacks registered with an B<AtExit> object are executed at
I<object-destruction time>! The rules for order of execution of the
registered subroutines are the same for objects during
object-destruction, as for the program during program-termination.

The B<atexit> function/method should be passed a subroutine name or
reference, optionally followed by the list of arguments with which to
invoke it at program/object exit time.  Anonymous subroutine references
passed to B<atexit> act as "closures" (which are described in
L<perlref>).  If a subroutine I<name> is specified (as opposed to a
subroutine reference) then, unless the subroutine name has an explicit

lib/AtExit.pm  view on Meta::CPAN

B<AtExit> object and invokes each one in turn (each subroutine is
removed from the front of the queue immediately before it is invoked).
At program-exit time, the C<END{}> block in the B<AtExit> module
iterates over the subroutines in the array returned by the
B<exit_subs> method and invokes each one in turn (each subroutine is
removed from the front of the queue immediately before it is invoked).
Note that in both cases (program-exit, and object-destruction) the
subroutines in this queue are invoked in first-to-last order (the
I<reverse> order in which they were registered with B<atexit>).

=head2 Adding and removing callbacks during exit/destruction time.

The method B<ignore_when_exiting> specifies how exit-callback
registration and unregistration will be handled during program-exit
or object-destruction time, while exit-callbacks are in process
of being invoked.

When invoked as a class method (e.g., C<AtExit-E<gt>ignore_when_exiting>),
B<ignore_when_exiting> corresponds to the handling of calls to
B<atexit> and B<rmexit> during program-termination. But when invoked as
an I<object> method (e.g., C<$exitObject-E<gt>ignore_when_exiting>), then
B<ignore_when_exiting> corresponds to the handling of calls to
B<atexit> and B<rmexit> during I<object-destruction> for the particular
object.

lib/AtExit.pm  view on Meta::CPAN

routines registered using B<atexit> are currently in the process of
being invoked. It will be non-zero if they are and zero otherwise. When
invoked as a class method (e.g., C<AtExit-E<gt>is_exiting>), the return
value will correspond to program-exit processing; but when invoked as
an I<object> method (e.g., C<$exitObject-E<gt>is_exiting>) the return
value will correspond to object-destruction processing for the given
object.

If, for any reason, the list of registered callback needs to be directly
accessed or manipulated, the B<exit_subs> function will return a reference
to the list of program-exit callbacks. When invoked as a method, B<exit_subs>
will return a reference to the list of object-destruction callbacks for the
corresponding object.

=head1 EXPORTS

For backward compatibility, B<atexit> and B<rmexit> are exported
by default. I<Note> however that B<exit_subs>, B<is_exiting>, and
B<ignore_when_exiting> are I<not> exported by default, and should
be invoked as class methods (e.g. C<AtExit-E<gt>is_exiting>) if
they are to manipulate program-exit information (rather than
object-destruction) and not explicitly imported.