{
    "mode": "man",
    "parameter": "PERLMOD",
    "section": "1",
    "url": "https://www.chedong.com/phpMan.php/man/PERLMOD/1/json",
    "generated": "2026-10-05T09:54:26Z",
    "sections": {
        "NAME": {
            "content": "perlmod - Perl modules (packages and symbol tables)\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "",
            "subsections": [
                {
                    "name": "Is this the document you were after?",
                    "content": "There are other documents which might contain the information that you're looking for:\n\nThis doc\nPerl's packages, namespaces, and some info on classes.\n\nperlnewmod\nTutorial on making a new module.\n\nperlmodstyle\nBest practices for making a new module.\n"
                },
                {
                    "name": "Packages",
                    "content": "Unlike  Perl  4,  in  which  all the variables were dynamic and shared one global name space,\ncausing maintainability problems, Perl 5 provides two mechanisms  for  protecting  code  from\nhaving  its  variables stomped on by other code: lexically scoped variables created with \"my\"\nor \"state\" and namespaced global variables, which are exposed via the \"vars\" pragma,  or  the\n\"our\"  keyword.  Any  global  variable  is  considered  to  be part of a namespace and can be\naccessed via a  \"fully  qualified  form\".   Conversely,  any  lexically  scoped  variable  is\nconsidered to be part of that lexical-scope, and does not have a \"fully qualified form\".\n\nIn  perl  namespaces  are  called \"packages\" and the \"package\" declaration tells the compiler\nwhich namespace to prefix to \"our\"  variables  and  unqualified  dynamic  names.   This  both\nprotects  against  accidental  stomping and provides an interface for deliberately clobbering\nglobal dynamic variables declared and used in other scopes or packages, when that is what you\nwant to do.\n\nThe scope of the \"package\" declaration is from the declaration itself through the end of  the\nenclosing  block,  \"eval\", or file, whichever comes first (the same scope as the my(), our(),\nstate(), and local() operators, and also the effect of the experimental \"reference aliasing,\"\nwhich may change), or until the next \"package\" declaration.  Unqualified dynamic  identifiers\nwill  be in this namespace, except for those few identifiers that, if unqualified, default to\nthe main package instead of the current  one  as  described  below.   A  \"package\"  statement\naffects  only  dynamic  global symbols, including subroutine names, and variables you've used\nlocal() on, but not lexical variables created with my(), our() or state().\n\nTypically, a \"package\" statement is the first declaration in a file included in a program  by\none  of  the \"do\", \"require\", or \"use\" operators.  You can switch into a package in more than\none place: \"package\" has no effect beyond specifying which symbol table the compiler will use\nfor dynamic symbols for the rest of that block or until the next  \"package\"  statement.   You\ncan refer to variables and filehandles in other packages by prefixing the identifier with the\npackage name and a double colon: $Package::Variable.  If the package name is null, the \"main\"\npackage is assumed.  That is, $::sail is equivalent to $main::sail.\n\nThe  old  package  delimiter  was  a  single  quote,  but  double  colon is now the preferred\ndelimiter, in part because it's more readable to  humans,  and  in  part  because  it's  more\nreadable  to  emacs  macros.   It also makes C++ programmers feel like they know what's going\non--as opposed to using  the  single  quote  as  separator,  which  was  there  to  make  Ada\nprogrammers feel like they knew what was going on.  Because the old-fashioned syntax is still\nsupported  for  backwards  compatibility,  if  you try to use a string like \"This is $owner's\nhouse\", you'll be accessing $owner::s; that is, the $s variable in package \"owner\", which  is\nprobably not what you meant.  Use braces to disambiguate, as in \"This is ${owner}'s house\".\n\nUsing \"'\" as a package separator is deprecated and will be removed in Perl 5.40.\n\nPackages  may  themselves contain package separators, as in $OUTER::INNER::var.  This implies\nnothing about the order of name lookups,  however.   There  are  no  relative  packages:  all\nsymbols  are  either  local to the current package, or must be fully qualified from the outer\npackage name down.  For instance, there is nowhere within package  \"OUTER\"  that  $INNER::var\nrefers  to  $OUTER::INNER::var.   \"INNER\"  refers  to  a totally separate global package. The\ncustom of treating package names as a hierarchy is very strong, but the language  in  no  way\nenforces it.\n\nOnly  identifiers  starting  with  letters  (or  underscore) are stored in a package's symbol\ntable.  All other symbols are kept in package \"main\", including  all  punctuation  variables,\nlike  $.   In  addition,  when  unqualified,  the  identifiers  STDIN, STDOUT, STDERR, ARGV,\nARGVOUT, ENV, INC, and SIG are forced to be in package  \"main\",  even  when  used  for  other\npurposes  than  their built-in ones.  If you have a package called \"m\", \"s\", or \"y\", then you\ncan't use the qualified form of an identifier because it would be instead  interpreted  as  a\npattern match, a substitution, or a transliteration.\n\nVariables  beginning  with  underscore used to be forced into package main, but we decided it\nwas more useful for package writers to be able to use leading underscore to indicate  private\nvariables  and  method names.  However, variables and functions named with a single \"\", such\nas $ and \"sub \", are still forced into  the  package  \"main\".   See  also  \"The  Syntax  of\nVariable Names\" in perlvar.\n\n\"eval\"ed  strings are compiled in the package in which the eval() was compiled.  (Assignments\nto \"$SIG{}\", however, assume the signal handler specified is in the \"main\" package.   Qualify\nthe  signal handler name if you wish to have a signal handler in a package.)  For an example,\nexamine perldb.pl in the Perl library.  It initially switches to the \"DB\" package so that the\ndebugger doesn't interfere with variables in the program you are trying to debug.  At various\npoints, however, it temporarily switches back to  the  \"main\"  package  to  evaluate  various\nexpressions in the context of the \"main\" package (or wherever you came from).  See perldebug.\n\nThe special symbol \"PACKAGE\" contains the current package, but cannot (easily) be used to\nconstruct  variable  names.  After my($foo) has hidden package variable $foo, it can still be\naccessed, without knowing what package you are in, as \"${PACKAGE.'::foo'}\".\n\nSee perlsub for other scoping issues related to  my()  and  local(),  and  perlref  regarding\nclosures.\n"
                },
                {
                    "name": "Symbol Tables",
                    "content": "The  symbol table for a package happens to be stored in the hash of that name with two colons\nappended.  The main symbol table's name is thus %main::, or  %::  for  short.   Likewise  the\nsymbol table for the nested package mentioned earlier is named %OUTER::INNER::.\n\nThe  value  in  each  entry  of  the hash is what you are referring to when you use the *name\ntypeglob notation.\n\nlocal *main::foo    = *main::bar;\n\nYou can use this to print out all the variables in a package, for instance.  The standard but\nantiquated dumpvar.pl library and the CPAN module Devel::Symdump make use of this.\n\nThe results of creating new symbol table entries directly or modifying any entries  that  are\nnot already typeglobs are undefined and subject to change between releases of perl.\n\nAssignment to a typeglob performs an aliasing operation, i.e.,\n\n*dick = *richard;\n\ncauses  variables,  subroutines,  formats,  and file and directory handles accessible via the\nidentifier \"richard\" also to be accessible via the identifier \"dick\".  If you want  to  alias\nonly a particular variable or subroutine, assign a reference instead:\n\n*dick = \\$richard;\n\nWhich  makes  $richard and $dick the same variable, but leaves @richard and @dick as separate\narrays.  Tricky, eh?\n\nThere is one subtle difference between the following statements:\n\n*foo = *bar;\n*foo = \\$bar;\n\n\"*foo = *bar\" makes the typeglobs themselves synonymous while \"*foo = \\$bar\" makes the SCALAR\nportions of two distinct typeglobs refer to the  same  scalar  value.  This  means  that  the\nfollowing code:\n\n$bar = 1;\n*foo = \\$bar;       # Make $foo an alias for $bar\n\n{\nlocal $bar = 2; # Restrict changes to block\nprint $foo;     # Prints '1'!\n}\n\nWould  print  '1',  because  $foo  holds  a  reference to the original $bar. The one that was\nstuffed away by local() and which will be restored when the block ends. Because variables are\naccessed through the typeglob, you can use \"*foo = *bar\" to create  an  alias  which  can  be\nlocalized. (But be aware that this means you can't have a separate @foo and @bar, etc.)\n\nWhat  makes  all  of  this  important  is  that the Exporter module uses glob aliasing as the\nimport/export mechanism. Whether or not you can properly localize a variable  that  has  been\nexported from a module depends on how it was exported:\n\n@EXPORT = qw($FOO); # Usual form, can't be localized\n@EXPORT = qw(*FOO); # Can be localized\n\nYou  can  work  around the first case by using the fully qualified name ($Package::FOO) where\nyou need a local value, or by overriding it by saying \"*FOO = *Package::FOO\" in your script.\n\nThe \"*x = \\$y\" mechanism may be used to  pass  and  return  cheap  references  into  or  from\nsubroutines  if  you  don't  want  to  copy the whole thing.  It only works when assigning to\ndynamic variables, not lexicals.\n\n%somehash = ();                    # can't be my()\n*somehash = fn( \\%anotherhash );\nsub fn {\nlocal *hashsym = shift;\n# now use %hashsym normally, and you\n# will affect the caller's %anotherhash\nmy %nhash = (); # do what you want\nreturn \\%nhash;\n}\n\nOn return, the reference will overwrite the hash slot in the symbol table  specified  by  the\n*somehash typeglob.  This is a somewhat tricky way of passing around references cheaply when\nyou don't want to have to remember to dereference variables explicitly.\n\nAnother use of symbol tables is for making \"constant\" scalars.\n\n*PI = \\3.14159265358979;\n\nNow  you cannot alter $PI, which is probably a good thing all in all.  This isn't the same as\na constant subroutine,  which  is  subject  to  optimization  at  compile-time.   A  constant\nsubroutine  is  one prototyped to take no arguments and to return a constant expression.  See\nperlsub for details on these.  The \"use constant\" pragma is a convenient shorthand for these.\n\nYou can say *foo{PACKAGE} and *foo{NAME} to find out what name and package  the  *foo  symbol\ntable  entry  comes  from.   This may be useful in a subroutine that gets passed typeglobs as\narguments:\n\nsub identifytypeglob {\nmy $glob = shift;\nprint 'You gave me ', *{$glob}{PACKAGE},\n'::', *{$glob}{NAME}, \"\\n\";\n}\nidentifytypeglob *foo;\nidentifytypeglob *bar::baz;\n\nThis prints\n\nYou gave me main::foo\nYou gave me bar::baz\n\nThe *foo{THING} notation can also be used to obtain references to the individual elements  of\n*foo.  See perlref.\n\nSubroutine  definitions  (and declarations, for that matter) need not necessarily be situated\nin the package whose symbol table they occupy.  You  can  define  a  subroutine  outside  its\npackage by explicitly qualifying the name of the subroutine:\n\npackage main;\nsub Somepackage::foo { ... }   # &foo defined in Somepackage\n\nThis is just a shorthand for a typeglob assignment at compile time:\n\nBEGIN { *Somepackage::foo = sub { ... } }\n\nand is not the same as writing:\n\n{\npackage Somepackage;\nsub foo { ... }\n}\n\nIn  the  first two versions, the body of the subroutine is lexically in the main package, not\nin Somepackage. So something like this:\n\npackage main;\n\n$Somepackage::name = \"fred\";\n$main::name = \"barney\";\n\nsub Somepackage::foo {\nprint \"in \", PACKAGE, \": \\$name is '$name'\\n\";\n}\n\nSomepackage::foo();\n\nprints:\n\nin main: $name is 'barney'\n\nrather than:\n\nin Somepackage: $name is 'fred'\n\nThis also has implications for the use of the SUPER:: qualifier (see perlobj).\n"
                },
                {
                    "name": "BEGIN, UNITCHECK, CHECK, INIT and END",
                    "content": "Five specially named code blocks are executed at the beginning and at the end  of  a  running\nPerl program.  These are the \"BEGIN\", \"UNITCHECK\", \"CHECK\", \"INIT\", and \"END\" blocks.\n\nThese code blocks can be prefixed with \"sub\" to give the appearance of a subroutine (although\nthis  is  not  considered  good  style).  One should note that these code blocks don't really\nexist as named subroutines (despite their appearance). The thing that gives this away is  the\nfact that you can have more than one of these code blocks in a program, and they will get all\nexecuted at the appropriate moment.  So you can't execute any of these code blocks by name.\n\nA  \"BEGIN\"  code  block is executed as soon as possible, that is, the moment it is completely\ndefined, even before the rest of the containing file (or string) is  parsed.   You  may  have\nmultiple  \"BEGIN\"  blocks  within  a  file (or eval'ed string); they will execute in order of\ndefinition.  Because a \"BEGIN\" code block executes immediately, it can pull in definitions of\nsubroutines and such from other files in time to be visible to the rest of  the  compile  and\nrun  time.   Once  a  \"BEGIN\"  has  run,  it is immediately undefined and any code it used is\nreturned to Perl's memory pool.\n\nAn \"END\" code block is executed as late as possible, that is, after perl has finished running\nthe program and just before the interpreter is being exited, even  if  it  is  exiting  as  a\nresult  of  a  die() function.  (But not if it's morphing into another program via \"exec\", or\nbeing blown out of the water by a signal--you have to trap that yourself (if you can).)   You\nmay  have  multiple  \"END\"  blocks  within  a  file--they  will  execute  in reverse order of\ndefinition; that is: last in, first out (LIFO).  \"END\" blocks are not executed when  you  run\nperl with the \"-c\" switch, or if compilation fails.\n\nNote that \"END\" code blocks are not executed at the end of a string eval(): if any \"END\" code\nblocks  are  created  in  a string eval(), they will be executed just as any other \"END\" code\nblock of that package in LIFO order just before the interpreter is being exited.\n\nInside an \"END\" code block, $? contains the value that  the  program  is  going  to  pass  to\nexit().  You can modify $? to change the exit value of the program.  Beware of changing $? by\naccident (e.g. by running something via \"system\").\n\nInside of a \"END\" block, the value of \"${^GLOBALPHASE}\" will be \"END\".\n\nSimilar  to  an  \"END\"  block  are  \"defer\"  blocks,  though  they operate on the lifetime of\nindividual block scopes, rather than the program as a whole. They are documented  in  \"defer\"\nin perlsyn.\n\n\"UNITCHECK\",  \"CHECK\"  and  \"INIT\" code blocks are useful to catch the transition between the\ncompilation phase and the execution phase of the main program.\n\n\"UNITCHECK\" blocks are run just after the unit which defined them  has  been  compiled.   The\nmain program file and each module it loads are compilation units, as are string \"eval\"s, run-\ntime  code  compiled  using  the  \"(?{ })\" construct in a regex, calls to \"do FILE\", \"require\nFILE\", and code after the \"-e\" switch on the command line.\n\n\"BEGIN\" and \"UNITCHECK\" blocks are not directly related to  the  phase  of  the  interpreter.\nThey can be created and executed during any phase.\n\n\"CHECK\" code blocks are run just after the initial Perl compile phase ends and before the run\ntime  begins, in LIFO order.  \"CHECK\" code blocks are used in the Perl compiler suite to save\nthe compiled state of the program.\n\nInside of a \"CHECK\" block, the value of \"${^GLOBALPHASE}\" will be \"CHECK\".\n\n\"INIT\" blocks are run just before the Perl runtime begins execution, in \"first in, first out\"\n(FIFO) order.\n\nInside of an \"INIT\" block, the value of \"${^GLOBALPHASE}\" will be \"INIT\".\n\nThe \"CHECK\" and \"INIT\" blocks in code compiled by \"require\", string \"do\",  or  string  \"eval\"\nwill not be executed if they occur after the end of the main compilation phase; that can be a\nproblem  in modperl and other persistent environments which use those functions to load code\nat runtime.\n\nWhen you use the -n and -p switches to Perl, \"BEGIN\" and \"END\" work just as they do  in  awk,\nas a degenerate case.  Both \"BEGIN\" and \"CHECK\" blocks are run when you use the -c switch for\na compile-only syntax check, although your main code is not.\n\nThe begincheck program makes it all clear, eventually:\n\n#!/usr/bin/perl\n\n# begincheck\n\nprint         \"10. Ordinary code runs at runtime.\\n\";\n\nEND { print   \"16.   So this is the end of the tale.\\n\" }\nINIT { print  \" 7. INIT blocks run FIFO just before runtime.\\n\" }\nUNITCHECK {\nprint       \" 4.   And therefore before any CHECK blocks.\\n\"\n}\nCHECK { print \" 6.   So this is the sixth line.\\n\" }\n\nprint         \"11.   It runs in order, of course.\\n\";\n\nBEGIN { print \" 1. BEGIN blocks run FIFO during compilation.\\n\" }\nEND { print   \"15.   Read perlmod for the rest of the story.\\n\" }\nCHECK { print \" 5. CHECK blocks run LIFO after all compilation.\\n\" }\nINIT { print  \" 8.   Run this again, using Perl's -c switch.\\n\" }\n\nprint         \"12.   This is anti-obfuscated code.\\n\";\n\nEND { print   \"14. END blocks run LIFO at quitting time.\\n\" }\nBEGIN { print \" 2.   So this line comes out second.\\n\" }\nUNITCHECK {\nprint \" 3. UNITCHECK blocks run LIFO after each file is compiled.\\n\"\n}\nINIT { print  \" 9.   You'll see the difference right away.\\n\" }\n\nprint         \"13.   It only looks like it should be confusing.\\n\";\n\nEND\n"
                },
                {
                    "name": "Perl Classes",
                    "content": "There  is  no  special  class syntax in Perl, but a package may act as a class if it provides\nsubroutines to act as methods.  Such a package may also  derive  some  of  its  methods  from\nanother  class (package) by listing the other package name(s) in its global @ISA array (which\nmust be a package global, not a lexical).\n\nFor more on this, see perlootut and perlobj.\n"
                },
                {
                    "name": "Perl Modules",
                    "content": "A module is just a set of related functions in a library file, i.e., a Perl package with  the\nsame  name  as  the  file.   It  is  specifically designed to be reusable by other modules or\nprograms.  It may do this by providing a mechanism for exporting some of its symbols into the\nsymbol table of any package using it, or it may function as a class definition and  make  its\nsemantics  available  implicitly  through  method calls on the class and its objects, without\nexplicitly exporting anything.  Or it can do a little of both.\n\nFor example, to start a traditional, non-OO module called Some::Module, create a file  called\nSome/Module.pm and start with this template:\n\npackage Some::Module;  # assumes Some/Module.pm\n\nuse v5.36;\n\n# Get the import method from Exporter to export functions and\n# variables\nuse Exporter 5.57 'import';\n\n# set the version for version checking\nour $VERSION     = '1.00';\n\n# Functions and variables which are exported by default\nour @EXPORT      = qw(func1 func2);\n\n# Functions and variables which can be optionally exported\nour @EXPORTOK   = qw($Var1 %Hashit func3);\n\n# exported package globals go here\nour $Var1    = '';\nour %Hashit  = ();\n\n# non-exported package globals go here\n# (they are still accessible as $Some::Module::stuff)\nour @more    = ();\nour $stuff   = '';\n\n# file-private lexicals go here, before any functions which use them\nmy $privvar    = '';\nmy %secrethash = ();\n\n# here's a file-private function as a closure,\n# callable as $privfunc->();\nmy $privfunc = sub {\n...\n};\n\n# make all your functions, whether exported or not;\n# remember to put something interesting in the {} stubs\nsub func1      { ... }\nsub func2      { ... }\n\n# this one isn't always exported, but could be called directly\n# as Some::Module::func3()\nsub func3      { ... }\n\nEND { ... }       # module clean-up code here (global destructor)\n\n1;  # don't forget to return a true value from the file\n\nThen  go  on  to declare and use your variables in functions without any qualifications.  See\nExporter and the perlmodlib for details on mechanics and style issues in module creation.\n\nPerl modules are included into your program by saying\n\nuse Module;\n\nor\n\nuse Module LIST;\n\nThis is exactly equivalent to\n\nBEGIN { require 'Module.pm'; 'Module'->import; }\n\nor\n\nBEGIN { require 'Module.pm'; 'Module'->import( LIST ); }\n\nAs a special case\n\nuse Module ();\n\nis exactly equivalent to\n\nBEGIN { require 'Module.pm'; }\n\nAll Perl module files have the extension .pm.  The \"use\" operator assumes this so  you  don't\nhave  to  spell out \"Module.pm\" in quotes.  This also helps to differentiate new modules from\nold .pl and .ph files.  Module names are  also  capitalized  unless  they're  functioning  as\npragmas;  pragmas  are  in  effect  compiler  directives, and are sometimes called \"pragmatic\nmodules\" (or even \"pragmata\" if you're a classicist).\n\nThe two statements:\n\nrequire SomeModule;\nrequire \"SomeModule.pm\";\n\ndiffer from each other in two ways.  In the first case, any double colons in the module name,\nsuch as \"Some::Module\", are translated into your system's directory separator,  usually  \"/\".\nThe  second case does not, and would have to be specified literally.  The other difference is\nthat seeing the first \"require\" clues in the compiler that uses of indirect  object  notation\ninvolving \"SomeModule\", as in \"$ob = purge SomeModule\", are method calls, not function calls.\n(Yes, this really can make a difference.)\n\nBecause  the  \"use\"  statement implies a \"BEGIN\" block, the importing of semantics happens as\nsoon as the \"use\" statement is compiled, before the rest of the file is  compiled.   This  is\nhow  it  is  able to function as a pragma mechanism, and also how modules are able to declare\nsubroutines that are then visible as list or unary operators for  the  rest  of  the  current\nfile.   This will not work if you use \"require\" instead of \"use\".  With \"require\" you can get\ninto this problem:\n\nrequire Cwd;                # make Cwd:: accessible\n$here = Cwd::getcwd();\n\nuse Cwd;                    # import names from Cwd::\n$here = getcwd();\n\nrequire Cwd;                # make Cwd:: accessible\n$here = getcwd();           # oops! no main::getcwd()\n\nIn general, \"use Module ()\" is recommended  over  \"require  Module\",  because  it  determines\nmodule  availability  at  compile  time,  not  in the middle of your program's execution.  An\nexception would be if two modules each tried to \"use\" each other,  and  each  also  called  a\nfunction from that other module.  In that case, it's easy to use \"require\" instead.\n\nPerl  packages  may  be  nested  inside  other  package  names,  so we can have package names\ncontaining \"::\".  But if we used that package name directly as a filename it would  make  for\nunwieldy  or  impossible  filenames  on some systems.  Therefore, if a module's name is, say,\n\"Text::Soundex\", then its definition is actually found in the library file Text/Soundex.pm.\n\nPerl modules always have a .pm file, but there may also  be  dynamically  linked  executables\n(often  ending  in .so) or autoloaded subroutine definitions (often ending in .al) associated\nwith the module.  If so, these will be entirely transparent to the user of the module.  It is\nthe responsibility of  the  .pm  file  to  load  (or  arrange  to  autoload)  any  additional\nfunctionality.  For example, although the POSIX module happens to do both dynamic loading and\nautoloading, the user can say just \"use POSIX\" to get it all.\n"
                },
                {
                    "name": "Making your module threadsafe",
                    "content": "Perl  supports a type of threads called interpreter threads (ithreads).  These threads can be\nused explicitly and implicitly.\n\nIthreads work by cloning the data tree so that no data is shared between  different  threads.\nThese  threads  can  be  used by using the \"threads\" module or by doing fork() on win32 (fake\nfork() support). When a thread is cloned all Perl  data  is  cloned,  however  non-Perl  data\ncannot  be  cloned  automatically.   Perl  after  5.8.0  has  support for the \"CLONE\" special\nsubroutine.  In \"CLONE\" you can do whatever you need to  do,  like  for  example  handle  the\ncloning  of  non-Perl  data, if necessary.  \"CLONE\" will be called once as a class method for\nevery package that has it defined (or inherits it).  It will be called in the context of  the\nnew thread, so all modifications are made in the new area.  Currently CLONE is called with no\nparameters  other  than  the invocant package name, but code should not assume that this will\nremain unchanged, as it is likely that in future extra parameters will be passed in  to  give\nmore information about the state of cloning.\n\nIf  you  want  to  CLONE all objects you will need to keep track of them per package. This is\nsimply done using a hash and Scalar::Util::weaken().\n\nPerl after 5.8.7  has  support  for  the  \"CLONESKIP\"  special  subroutine.   Like  \"CLONE\",\n\"CLONESKIP\"  is  called  once per package; however, it is called just before cloning starts,\nand in the context of the parent thread. If it returns a true value, then no objects of  that\nclass  will  be  cloned;  or  rather,  they  will  be copied as unblessed, undef values.  For\nexample: if in the parent there are two references to a single  blessed  hash,  then  in  the\nchild there will be two references to a single undefined scalar value instead.  This provides\na simple mechanism for making a module threadsafe; just add \"sub CLONESKIP { 1 }\" at the top\nof  the class, and DESTROY() will now only be called once per object. Of course, if the child\nthread needs to make use of the objects, then a more sophisticated approach is needed.\n\nLike \"CLONE\", \"CLONESKIP\" is currently called with no parameters  other  than  the  invocant\npackage  name, although that may change. Similarly, to allow for future expansion, the return\nvalue should be a single 0 or 1 value.\n"
                }
            ]
        },
        "SEE ALSO": {
            "content": "See perlmodlib for general style issues related to building Perl modules and classes, as well\nas descriptions  of  the  standard  library  and  CPAN,  Exporter  for  how  Perl's  standard\nimport/export  mechanism  works,  perlootut  and perlobj for in-depth information on creating\nclasses, perlobj for a hard-core reference document on objects, perlsub for an explanation of\nfunctions and scoping, and perlxstut and perlguts for more information on  writing  extension\nmodules.\n\nperl v5.38.2                                 2026-08-18                                   PERLMOD(1)",
            "subsections": []
        }
    },
    "summary": "perlmod - Perl modules (packages and symbol tables)",
    "flags": [],
    "examples": [],
    "see_also": []
}