[Summary view] [Print] [Text view]

   1  =head1 NAME
   2  
   3  perlmod - Perl modules (packages and symbol tables)
   4  
   5  =head1 DESCRIPTION
   6  
   7  =head2 Packages
   8  X<package> X<namespace> X<variable, global> X<global variable> X<global>
   9  
  10  Perl provides a mechanism for alternative namespaces to protect
  11  packages from stomping on each other's variables.  In fact, there's
  12  really no such thing as a global variable in Perl.  The package
  13  statement declares the compilation unit as being in the given
  14  namespace.  The scope of the package declaration is from the
  15  declaration itself through the end of the enclosing block, C<eval>,
  16  or file, whichever comes first (the same scope as the my() and
  17  local() operators).  Unqualified dynamic identifiers will be in
  18  this namespace, except for those few identifiers that if unqualified,
  19  default to the main package instead of the current one as described
  20  below.  A package statement affects only dynamic variables--including
  21  those you've used local() on--but I<not> lexical variables created
  22  with my().  Typically it would be the first declaration in a file
  23  included by the C<do>, C<require>, or C<use> operators.  You can
  24  switch into a package in more than one place; it merely influences
  25  which symbol table is used by the compiler for the rest of that
  26  block.  You can refer to variables and filehandles in other packages
  27  by prefixing the identifier with the package name and a double
  28  colon: C<$Package::Variable>.  If the package name is null, the
  29  C<main> package is assumed.  That is, C<$::sail> is equivalent to
  30  C<$main::sail>.
  31  
  32  The old package delimiter was a single quote, but double colon is now the
  33  preferred delimiter, in part because it's more readable to humans, and
  34  in part because it's more readable to B<emacs> macros.  It also makes C++
  35  programmers feel like they know what's going on--as opposed to using the
  36  single quote as separator, which was there to make Ada programmers feel
  37  like they knew what was going on.  Because the old-fashioned syntax is still
  38  supported for backwards compatibility, if you try to use a string like
  39  C<"This is $owner's house">, you'll be accessing C<$owner::s>; that is,
  40  the $s variable in package C<owner>, which is probably not what you meant.
  41  Use braces to disambiguate, as in C<"This is $owner}'s house">.
  42  X<::> X<'>
  43  
  44  Packages may themselves contain package separators, as in
  45  C<$OUTER::INNER::var>.  This implies nothing about the order of
  46  name lookups, however.  There are no relative packages: all symbols
  47  are either local to the current package, or must be fully qualified
  48  from the outer package name down.  For instance, there is nowhere
  49  within package C<OUTER> that C<$INNER::var> refers to
  50  C<$OUTER::INNER::var>.  C<INNER> refers to a totally
  51  separate global package.
  52  
  53  Only identifiers starting with letters (or underscore) are stored
  54  in a package's symbol table.  All other symbols are kept in package
  55  C<main>, including all punctuation variables, like $_.  In addition,
  56  when unqualified, the identifiers STDIN, STDOUT, STDERR, ARGV,
  57  ARGVOUT, ENV, INC, and SIG are forced to be in package C<main>,
  58  even when used for other purposes than their built-in ones.  If you
  59  have a package called C<m>, C<s>, or C<y>, then you can't use the
  60  qualified form of an identifier because it would be instead interpreted
  61  as a pattern match, a substitution, or a transliteration.
  62  X<variable, punctuation> 
  63  
  64  Variables beginning with underscore used to be forced into package
  65  main, but we decided it was more useful for package writers to be able
  66  to use leading underscore to indicate private variables and method names.
  67  However, variables and functions named with a single C<_>, such as
  68  $_ and C<sub _>, are still forced into the package C<main>.  See also
  69  L<perlvar/"Technical Note on the Syntax of Variable Names">.
  70  
  71  C<eval>ed strings are compiled in the package in which the eval() was
  72  compiled.  (Assignments to C<$SIG{}>, however, assume the signal
  73  handler specified is in the C<main> package.  Qualify the signal handler
  74  name if you wish to have a signal handler in a package.)  For an
  75  example, examine F<perldb.pl> in the Perl library.  It initially switches
  76  to the C<DB> package so that the debugger doesn't interfere with variables
  77  in the program you are trying to debug.  At various points, however, it
  78  temporarily switches back to the C<main> package to evaluate various
  79  expressions in the context of the C<main> package (or wherever you came
  80  from).  See L<perldebug>.
  81  
  82  The special symbol C<__PACKAGE__> contains the current package, but cannot
  83  (easily) be used to construct variable names.
  84  
  85  See L<perlsub> for other scoping issues related to my() and local(),
  86  and L<perlref> regarding closures.
  87  
  88  =head2 Symbol Tables
  89  X<symbol table> X<stash> X<%::> X<%main::> X<typeglob> X<glob> X<alias>
  90  
  91  The symbol table for a package happens to be stored in the hash of that
  92  name with two colons appended.  The main symbol table's name is thus
  93  C<%main::>, or C<%::> for short.  Likewise the symbol table for the nested
  94  package mentioned earlier is named C<%OUTER::INNER::>.
  95  
  96  The value in each entry of the hash is what you are referring to when you
  97  use the C<*name> typeglob notation.  In fact, the following have the same
  98  effect, though the first is more efficient because it does the symbol
  99  table lookups at compile time:
 100  
 101      local *main::foo    = *main::bar;
 102      local $main::{foo}  = $main::{bar};
 103  
 104  (Be sure to note the B<vast> difference between the second line above
 105  and C<local $main::foo = $main::bar>. The former is accessing the hash
 106  C<%main::>, which is the symbol table of package C<main>. The latter is
 107  simply assigning scalar C<$bar> in package C<main> to scalar C<$foo> of
 108  the same package.)
 109  
 110  You can use this to print out all the variables in a package, for
 111  instance.  The standard but antiquated F<dumpvar.pl> library and
 112  the CPAN module Devel::Symdump make use of this.
 113  
 114  Assignment to a typeglob performs an aliasing operation, i.e.,
 115  
 116      *dick = *richard;
 117  
 118  causes variables, subroutines, formats, and file and directory handles
 119  accessible via the identifier C<richard> also to be accessible via the
 120  identifier C<dick>.  If you want to alias only a particular variable or
 121  subroutine, assign a reference instead:
 122  
 123      *dick = \$richard;
 124  
 125  Which makes $richard and $dick the same variable, but leaves
 126  @richard and @dick as separate arrays.  Tricky, eh?
 127  
 128  There is one subtle difference between the following statements:
 129  
 130      *foo = *bar;
 131      *foo = \$bar;
 132  
 133  C<*foo = *bar> makes the typeglobs themselves synonymous while
 134  C<*foo = \$bar> makes the SCALAR portions of two distinct typeglobs
 135  refer to the same scalar value. This means that the following code:
 136  
 137      $bar = 1;
 138      *foo = \$bar;       # Make $foo an alias for $bar
 139  
 140      {
 141          local $bar = 2; # Restrict changes to block
 142          print $foo;     # Prints '1'!
 143      }
 144  
 145  Would print '1', because C<$foo> holds a reference to the I<original>
 146  C<$bar> -- the one that was stuffed away by C<local()> and which will be
 147  restored when the block ends. Because variables are accessed through the
 148  typeglob, you can use C<*foo = *bar> to create an alias which can be
 149  localized. (But be aware that this means you can't have a separate
 150  C<@foo> and C<@bar>, etc.)
 151  
 152  What makes all of this important is that the Exporter module uses glob
 153  aliasing as the import/export mechanism. Whether or not you can properly
 154  localize a variable that has been exported from a module depends on how
 155  it was exported:
 156  
 157      @EXPORT = qw($FOO); # Usual form, can't be localized
 158      @EXPORT = qw(*FOO); # Can be localized
 159  
 160  You can work around the first case by using the fully qualified name
 161  (C<$Package::FOO>) where you need a local value, or by overriding it
 162  by saying C<*FOO = *Package::FOO> in your script.
 163  
 164  The C<*x = \$y> mechanism may be used to pass and return cheap references
 165  into or from subroutines if you don't want to copy the whole
 166  thing.  It only works when assigning to dynamic variables, not
 167  lexicals.
 168  
 169      %some_hash = ();            # can't be my()
 170      *some_hash = fn( \%another_hash );
 171      sub fn {
 172      local *hashsym = shift;
 173      # now use %hashsym normally, and you
 174      # will affect the caller's %another_hash
 175      my %nhash = (); # do what you want
 176      return \%nhash;
 177      }
 178  
 179  On return, the reference will overwrite the hash slot in the
 180  symbol table specified by the *some_hash typeglob.  This
 181  is a somewhat tricky way of passing around references cheaply
 182  when you don't want to have to remember to dereference variables
 183  explicitly.
 184  
 185  Another use of symbol tables is for making "constant" scalars.
 186  X<constant> X<scalar, constant>
 187  
 188      *PI = \3.14159265358979;
 189  
 190  Now you cannot alter C<$PI>, which is probably a good thing all in all.
 191  This isn't the same as a constant subroutine, which is subject to
 192  optimization at compile-time.  A constant subroutine is one prototyped
 193  to take no arguments and to return a constant expression.  See
 194  L<perlsub> for details on these.  The C<use constant> pragma is a
 195  convenient shorthand for these.
 196  
 197  You can say C<*foo{PACKAGE}> and C<*foo{NAME}> to find out what name and
 198  package the *foo symbol table entry comes from.  This may be useful
 199  in a subroutine that gets passed typeglobs as arguments:
 200  
 201      sub identify_typeglob {
 202          my $glob = shift;
 203          print 'You gave me ', *{$glob}{PACKAGE}, '::', *{$glob}{NAME}, "\n";
 204      }
 205      identify_typeglob *foo;
 206      identify_typeglob *bar::baz;
 207  
 208  This prints
 209  
 210      You gave me main::foo
 211      You gave me bar::baz
 212  
 213  The C<*foo{THING}> notation can also be used to obtain references to the
 214  individual elements of *foo.  See L<perlref>.
 215  
 216  Subroutine definitions (and declarations, for that matter) need
 217  not necessarily be situated in the package whose symbol table they
 218  occupy.  You can define a subroutine outside its package by
 219  explicitly qualifying the name of the subroutine:
 220  
 221      package main;
 222      sub Some_package::foo { ... }   # &foo defined in Some_package
 223  
 224  This is just a shorthand for a typeglob assignment at compile time:
 225  
 226      BEGIN { *Some_package::foo = sub { ... } }
 227  
 228  and is I<not> the same as writing:
 229  
 230      {
 231      package Some_package;
 232      sub foo { ... }
 233      }
 234  
 235  In the first two versions, the body of the subroutine is
 236  lexically in the main package, I<not> in Some_package. So
 237  something like this:
 238  
 239      package main;
 240  
 241      $Some_package::name = "fred";
 242      $main::name = "barney";
 243  
 244      sub Some_package::foo {
 245      print "in ", __PACKAGE__, ": \$name is '$name'\n";
 246      }
 247  
 248      Some_package::foo();
 249  
 250  prints:
 251  
 252      in main: $name is 'barney'
 253  
 254  rather than:
 255  
 256      in Some_package: $name is 'fred'
 257  
 258  This also has implications for the use of the SUPER:: qualifier
 259  (see L<perlobj>).
 260  
 261  =head2 BEGIN, UNITCHECK, CHECK, INIT and END
 262  X<BEGIN> X<UNITCHECK> X<CHECK> X<INIT> X<END>
 263  
 264  Five specially named code blocks are executed at the beginning and at
 265  the end of a running Perl program.  These are the C<BEGIN>,
 266  C<UNITCHECK>, C<CHECK>, C<INIT>, and C<END> blocks.
 267  
 268  These code blocks can be prefixed with C<sub> to give the appearance of a
 269  subroutine (although this is not considered good style).  One should note
 270  that these code blocks don't really exist as named subroutines (despite
 271  their appearance). The thing that gives this away is the fact that you can
 272  have B<more than one> of these code blocks in a program, and they will get
 273  B<all> executed at the appropriate moment.  So you can't execute any of
 274  these code blocks by name.
 275  
 276  A C<BEGIN> code block is executed as soon as possible, that is, the moment
 277  it is completely defined, even before the rest of the containing file (or
 278  string) is parsed.  You may have multiple C<BEGIN> blocks within a file (or
 279  eval'ed string) -- they will execute in order of definition.  Because a C<BEGIN>
 280  code block executes immediately, it can pull in definitions of subroutines
 281  and such from other files in time to be visible to the rest of the compile
 282  and run time.  Once a C<BEGIN> has run, it is immediately undefined and any
 283  code it used is returned to Perl's memory pool.
 284  
 285  It should be noted that C<BEGIN> and C<UNITCHECK> code blocks B<are>
 286  executed inside string C<eval()>'s.  The C<CHECK> and C<INIT> code
 287  blocks are B<not> executed inside a string eval, which e.g. can be a
 288  problem in a mod_perl environment.
 289  
 290  An C<END> code block is executed as late as possible, that is, after
 291  perl has finished running the program and just before the interpreter
 292  is being exited, even if it is exiting as a result of a die() function.
 293  (But not if it's morphing into another program via C<exec>, or
 294  being blown out of the water by a signal--you have to trap that yourself
 295  (if you can).)  You may have multiple C<END> blocks within a file--they
 296  will execute in reverse order of definition; that is: last in, first
 297  out (LIFO).  C<END> blocks are not executed when you run perl with the
 298  C<-c> switch, or if compilation fails.
 299  
 300  Note that C<END> code blocks are B<not> executed at the end of a string
 301  C<eval()>: if any C<END> code blocks are created in a string C<eval()>,
 302  they will be executed just as any other C<END> code block of that package
 303  in LIFO order just before the interpreter is being exited.
 304  
 305  Inside an C<END> code block, C<$?> contains the value that the program is
 306  going to pass to C<exit()>.  You can modify C<$?> to change the exit
 307  value of the program.  Beware of changing C<$?> by accident (e.g. by
 308  running something via C<system>).
 309  X<$?>
 310  
 311  C<UNITCHECK>, C<CHECK> and C<INIT> code blocks are useful to catch the
 312  transition between the compilation phase and the execution phase of
 313  the main program.
 314  
 315  C<UNITCHECK> blocks are run just after the unit which defined them has
 316  been compiled.  The main program file and each module it loads are
 317  compilation units, as are string C<eval>s, code compiled using the
 318  C<(?{ })> construct in a regex, calls to C<do FILE>, C<require FILE>,
 319  and code after the C<-e> switch on the command line.
 320  
 321  C<CHECK> code blocks are run just after the B<initial> Perl compile phase ends
 322  and before the run time begins, in LIFO order.  C<CHECK> code blocks are used
 323  in the Perl compiler suite to save the compiled state of the program.
 324  
 325  C<INIT> blocks are run just before the Perl runtime begins execution, in
 326  "first in, first out" (FIFO) order.
 327  
 328  When you use the B<-n> and B<-p> switches to Perl, C<BEGIN> and
 329  C<END> work just as they do in B<awk>, as a degenerate case.
 330  Both C<BEGIN> and C<CHECK> blocks are run when you use the B<-c>
 331  switch for a compile-only syntax check, although your main code
 332  is not.
 333  
 334  The B<begincheck> program makes it all clear, eventually:
 335  
 336    #!/usr/bin/perl
 337  
 338    # begincheck
 339  
 340    print         "10. Ordinary code runs at runtime.\n";
 341  
 342    END { print   "16.   So this is the end of the tale.\n" }
 343    INIT { print  " 7. INIT blocks run FIFO just before runtime.\n" }
 344    UNITCHECK {
 345      print       " 4.   And therefore before any CHECK blocks.\n"
 346    }
 347    CHECK { print " 6.   So this is the sixth line.\n" }
 348  
 349    print         "11.   It runs in order, of course.\n";
 350  
 351    BEGIN { print " 1. BEGIN blocks run FIFO during compilation.\n" }
 352    END { print   "15.   Read perlmod for the rest of the story.\n" }
 353    CHECK { print " 5. CHECK blocks run LIFO after all compilation.\n" }
 354    INIT { print  " 8.   Run this again, using Perl's -c switch.\n" }
 355  
 356    print         "12.   This is anti-obfuscated code.\n";
 357  
 358    END { print   "14. END blocks run LIFO at quitting time.\n" }
 359    BEGIN { print " 2.   So this line comes out second.\n" }
 360    UNITCHECK {
 361     print " 3. UNITCHECK blocks run LIFO after each file is compiled.\n"
 362    }
 363    INIT { print  " 9.   You'll see the difference right away.\n" }
 364  
 365    print         "13.   It merely _looks_ like it should be confusing.\n";
 366  
 367    __END__
 368  
 369  =head2 Perl Classes
 370  X<class> X<@ISA>
 371  
 372  There is no special class syntax in Perl, but a package may act
 373  as a class if it provides subroutines to act as methods.  Such a
 374  package may also derive some of its methods from another class (package)
 375  by listing the other package name(s) in its global @ISA array (which
 376  must be a package global, not a lexical).
 377  
 378  For more on this, see L<perltoot> and L<perlobj>.
 379  
 380  =head2 Perl Modules
 381  X<module>
 382  
 383  A module is just a set of related functions in a library file, i.e.,
 384  a Perl package with the same name as the file.  It is specifically
 385  designed to be reusable by other modules or programs.  It may do this
 386  by providing a mechanism for exporting some of its symbols into the
 387  symbol table of any package using it, or it may function as a class
 388  definition and make its semantics available implicitly through
 389  method calls on the class and its objects, without explicitly
 390  exporting anything.  Or it can do a little of both.
 391  
 392  For example, to start a traditional, non-OO module called Some::Module,
 393  create a file called F<Some/Module.pm> and start with this template:
 394  
 395      package Some::Module;  # assumes Some/Module.pm
 396  
 397      use strict;
 398      use warnings;
 399  
 400      BEGIN {
 401          use Exporter   ();
 402          our ($VERSION, @ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
 403  
 404          # set the version for version checking
 405          $VERSION     = 1.00;
 406          # if using RCS/CVS, this may be preferred
 407          $VERSION = sprintf "%d.%03d", q$Revision: 1.1 $ =~ /(\d+)/g;
 408  
 409          @ISA         = qw(Exporter);
 410          @EXPORT      = qw(&func1 &func2 &func4);
 411          %EXPORT_TAGS = ( );     # eg: TAG => [ qw!name1 name2! ],
 412  
 413          # your exported package globals go here,
 414          # as well as any optionally exported functions
 415          @EXPORT_OK   = qw($Var1 %Hashit &func3);
 416      }
 417      our @EXPORT_OK;
 418  
 419      # exported package globals go here
 420      our $Var1;
 421      our %Hashit;
 422  
 423      # non-exported package globals go here
 424      our @more;
 425      our $stuff;
 426  
 427      # initialize package globals, first exported ones
 428      $Var1   = '';
 429      %Hashit = ();
 430  
 431      # then the others (which are still accessible as $Some::Module::stuff)
 432      $stuff  = '';
 433      @more   = ();
 434  
 435      # all file-scoped lexicals must be created before
 436      # the functions below that use them.
 437  
 438      # file-private lexicals go here
 439      my $priv_var    = '';
 440      my %secret_hash = ();
 441  
 442      # here's a file-private function as a closure,
 443      # callable as &$priv_func;  it cannot be prototyped.
 444      my $priv_func = sub {
 445          # stuff goes here.
 446      };
 447  
 448      # make all your functions, whether exported or not;
 449      # remember to put something interesting in the {} stubs
 450      sub func1      {}    # no prototype
 451      sub func2()    {}    # proto'd void
 452      sub func3($$)  {}    # proto'd to 2 scalars
 453  
 454      # this one isn't exported, but could be called!
 455      sub func4(\%)  {}    # proto'd to 1 hash ref
 456  
 457      END { }       # module clean-up code here (global destructor)
 458  
 459      ## YOUR CODE GOES HERE
 460  
 461      1;  # don't forget to return a true value from the file
 462  
 463  Then go on to declare and use your variables in functions without
 464  any qualifications.  See L<Exporter> and the L<perlmodlib> for
 465  details on mechanics and style issues in module creation.
 466  
 467  Perl modules are included into your program by saying
 468  
 469      use Module;
 470  
 471  or
 472  
 473      use Module LIST;
 474  
 475  This is exactly equivalent to
 476  
 477      BEGIN { require Module; import Module; }
 478  
 479  or
 480  
 481      BEGIN { require Module; import Module LIST; }
 482  
 483  As a special case
 484  
 485      use Module ();
 486  
 487  is exactly equivalent to
 488  
 489      BEGIN { require Module; }
 490  
 491  All Perl module files have the extension F<.pm>.  The C<use> operator
 492  assumes this so you don't have to spell out "F<Module.pm>" in quotes.
 493  This also helps to differentiate new modules from old F<.pl> and
 494  F<.ph> files.  Module names are also capitalized unless they're
 495  functioning as pragmas; pragmas are in effect compiler directives,
 496  and are sometimes called "pragmatic modules" (or even "pragmata"
 497  if you're a classicist).
 498  
 499  The two statements:
 500  
 501      require SomeModule;
 502      require "SomeModule.pm";
 503  
 504  differ from each other in two ways.  In the first case, any double
 505  colons in the module name, such as C<Some::Module>, are translated
 506  into your system's directory separator, usually "/".   The second
 507  case does not, and would have to be specified literally.  The other
 508  difference is that seeing the first C<require> clues in the compiler
 509  that uses of indirect object notation involving "SomeModule", as
 510  in C<$ob = purge SomeModule>, are method calls, not function calls.
 511  (Yes, this really can make a difference.)
 512  
 513  Because the C<use> statement implies a C<BEGIN> block, the importing
 514  of semantics happens as soon as the C<use> statement is compiled,
 515  before the rest of the file is compiled.  This is how it is able
 516  to function as a pragma mechanism, and also how modules are able to
 517  declare subroutines that are then visible as list or unary operators for
 518  the rest of the current file.  This will not work if you use C<require>
 519  instead of C<use>.  With C<require> you can get into this problem:
 520  
 521      require Cwd;        # make Cwd:: accessible
 522      $here = Cwd::getcwd();
 523  
 524      use Cwd;            # import names from Cwd::
 525      $here = getcwd();
 526  
 527      require Cwd;            # make Cwd:: accessible
 528      $here = getcwd();         # oops! no main::getcwd()
 529  
 530  In general, C<use Module ()> is recommended over C<require Module>,
 531  because it determines module availability at compile time, not in the
 532  middle of your program's execution.  An exception would be if two modules
 533  each tried to C<use> each other, and each also called a function from
 534  that other module.  In that case, it's easy to use C<require> instead.
 535  
 536  Perl packages may be nested inside other package names, so we can have
 537  package names containing C<::>.  But if we used that package name
 538  directly as a filename it would make for unwieldy or impossible
 539  filenames on some systems.  Therefore, if a module's name is, say,
 540  C<Text::Soundex>, then its definition is actually found in the library
 541  file F<Text/Soundex.pm>.
 542  
 543  Perl modules always have a F<.pm> file, but there may also be
 544  dynamically linked executables (often ending in F<.so>) or autoloaded
 545  subroutine definitions (often ending in F<.al>) associated with the
 546  module.  If so, these will be entirely transparent to the user of
 547  the module.  It is the responsibility of the F<.pm> file to load
 548  (or arrange to autoload) any additional functionality.  For example,
 549  although the POSIX module happens to do both dynamic loading and
 550  autoloading, the user can say just C<use POSIX> to get it all.
 551  
 552  =head2 Making your module threadsafe
 553  X<threadsafe> X<thread safe>
 554  X<module, threadsafe> X<module, thread safe>
 555  X<CLONE> X<CLONE_SKIP> X<thread> X<threads> X<ithread>
 556  
 557  Since 5.6.0, Perl has had support for a new type of threads called
 558  interpreter threads (ithreads). These threads can be used explicitly
 559  and implicitly.
 560  
 561  Ithreads work by cloning the data tree so that no data is shared
 562  between different threads. These threads can be used by using the C<threads>
 563  module or by doing fork() on win32 (fake fork() support). When a
 564  thread is cloned all Perl data is cloned, however non-Perl data cannot
 565  be cloned automatically.  Perl after 5.7.2 has support for the C<CLONE>
 566  special subroutine.  In C<CLONE> you can do whatever
 567  you need to do,
 568  like for example handle the cloning of non-Perl data, if necessary.
 569  C<CLONE> will be called once as a class method for every package that has it
 570  defined (or inherits it).  It will be called in the context of the new thread,
 571  so all modifications are made in the new area.  Currently CLONE is called with
 572  no parameters other than the invocant package name, but code should not assume
 573  that this will remain unchanged, as it is likely that in future extra parameters
 574  will be passed in to give more information about the state of cloning.
 575  
 576  If you want to CLONE all objects you will need to keep track of them per
 577  package. This is simply done using a hash and Scalar::Util::weaken().
 578  
 579  Perl after 5.8.7 has support for the C<CLONE_SKIP> special subroutine.
 580  Like C<CLONE>, C<CLONE_SKIP> is called once per package; however, it is
 581  called just before cloning starts, and in the context of the parent
 582  thread. If it returns a true value, then no objects of that class will
 583  be cloned; or rather, they will be copied as unblessed, undef values.
 584  For example: if in the parent there are two references to a single blessed
 585  hash, then in the child there will be two references to a single undefined
 586  scalar value instead.
 587  This provides a simple mechanism for making a module threadsafe; just add
 588  C<sub CLONE_SKIP { 1 }> at the top of the class, and C<DESTROY()> will be
 589  now only be called once per object. Of course, if the child thread needs
 590  to make use of the objects, then a more sophisticated approach is
 591  needed.
 592  
 593  Like C<CLONE>, C<CLONE_SKIP> is currently called with no parameters other
 594  than the invocant package name, although that may change. Similarly, to
 595  allow for future expansion, the return value should be a single C<0> or
 596  C<1> value.
 597  
 598  =head1 SEE ALSO
 599  
 600  See L<perlmodlib> for general style issues related to building Perl
 601  modules and classes, as well as descriptions of the standard library
 602  and CPAN, L<Exporter> for how Perl's standard import/export mechanism
 603  works, L<perltoot> and L<perltooc> for an in-depth tutorial on
 604  creating classes, L<perlobj> for a hard-core reference document on
 605  objects, L<perlsub> for an explanation of functions and scoping,
 606  and L<perlxstut> and L<perlguts> for more information on writing
 607  extension modules.