IPC::Shareable man page on Kali

Man page or keyword search:  
man Server   9211 pages
apropos Keyword Search (all sections)
Output format
Kali logo
[printable version]

IPC::Shareable(3pm)   User Contributed Perl Documentation  IPC::Shareable(3pm)

NAME
       IPC::Shareable - share Perl variables between processes

SYNOPSIS
	use IPC::Shareable (':lock');
	tie SCALAR, 'IPC::Shareable', GLUE, OPTIONS;
	tie ARRAY,  'IPC::Shareable', GLUE, OPTIONS;
	tie HASH,   'IPC::Shareable', GLUE, OPTIONS;

	(tied VARIABLE)->shlock;
	(tied VARIABLE)->shunlock;

	(tied VARIABLE)->shlock(LOCK_SH|LOCK_NB)
	       or print "resource unavailable\n";

	(tied VARIABLE)->remove;

	IPC::Shareable->clean_up;
	IPC::Shareable->clean_up_all;

CONVENTIONS
       The occurrence of a number in square brackets, as in [N], in the text
       of this document refers to a numbered note in the "NOTES".

DESCRIPTION
       IPC::Shareable allows you to tie a variable to shared memory making it
       easy to share the contents of that variable with other Perl processes.
       Scalars, arrays, and hashes can be tied.	 The variable being tied may
       contain arbitrarily complex data structures - including references to
       arrays, hashes of hashes, etc.

       The association between variables in distinct processes is provided by
       GLUE.  This is an integer number or 4 character string[1] that serves
       as a common identifier for data across process space.  Hence the
       statement

	tie $scalar, 'IPC::Shareable', 'data';

       in program one and the statement

	tie $variable, 'IPC::Shareable', 'data';

       in program two will bind $scalar in program one and $variable in
       program two.

       There is no pre-set limit to the number of processes that can bind to
       data; nor is there a pre-set limit to the complexity of the underlying
       data of the tied variables[2].  The amount of data that can be shared
       within a single bound variable is limited by the system's maximum size
       for a shared memory segment (the exact value is system-dependent).

       The bound data structures are all linearized (using Raphael Manfredi's
       Storable module) before being slurped into shared memory.  Upon
       retrieval, the original format of the data structure is recovered.
       Semaphore flags can be used for locking data between competing
       processes.

OPTIONS
       Options are specified by passing a reference to a hash as the fourth
       argument to the tie() function that enchants a variable.	 Alternatively
       you can pass a reference to a hash as the third argument;
       IPC::Shareable will then look at the field named key in this hash for
       the value of GLUE.  So,

	tie $variable, 'IPC::Shareable', 'data', \%options;

       is equivalent to

	tie $variable, 'IPC::Shareable', { key => 'data', ... };

       Boolean option values can be specified using a value that evaluates to
       either true or false in the Perl sense.

       NOTE: Earlier versions allowed you to use the word yes for true and the
       word no for false, but support for this "feature" is being removed.
       yes will still act as true (since it is true, in the Perl sense), but
       use of the word no now emits an (optional) warning and then converts to
       a false value.  This warning will become mandatory in a future release
       and then at some later date the use of no will stop working altogether.

       The following fields are recognized in the options hash.

       key The key field is used to determine the GLUE when using the three-
	   argument form of the call to tie().	This argument is then, in
	   turn, used as the KEY argument in subsequent calls to shmget() and
	   semget().

	   The default value is IPC_PRIVATE, meaning that your variables
	   cannot be shared with other processes.

       create
	   create is used to control whether calls to tie() create new shared
	   memory segments or not.  If create is set to a true value,
	   IPC::Shareable will create a new binding associated with GLUE as
	   needed.  If create is false, IPC::Shareable will not attempt to
	   create a new shared memory segment associated with GLUE.  In this
	   case, a shared memory segment associated with GLUE must already
	   exist or the call to tie() will fail and return undef.  The default
	   is false.

       exclusive
	   If exclusive field is set to a true value, calls to tie() will fail
	   (returning undef) if a data binding associated with GLUE already
	   exists.  If set to a false value, calls to tie() will succeed even
	   if a shared memory segment associated with GLUE already exists.
	   The default is false

       mode
	   The mode argument is an octal number specifying the access
	   permissions when a new data binding is being created.  These access
	   permission are the same as file access permissions in that 0666 is
	   world readable, 0600 is readable only by the effective UID of the
	   process creating the shared variable, etc.  The default is 0666
	   (world readable and writable).

       destroy
	   If set to a true value, the shared memory segment underlying the
	   data binding will be removed when the process calling tie() exits
	   (gracefully)[3].  Use this option with care.	 In particular you
	   should not use this option in a program that will fork after
	   binding the data.  On the other hand, shared memory is a finite
	   resource and should be released if it is not needed.	 The default
	   is false

       size
	   This field may be used to specify the size of the shared memory
	   segment allocated.  The default is IPC::Shareable::SHM_BUFSIZ().

       Default values for options are

	key	  => IPC_PRIVATE,
	create	  => 0,
	exclusive => 0,
	destroy	  => 0,
	mode	  => 0,
	size	  => IPC::Shareable::SHM_BUFSIZ(),

LOCKING
       IPC::Shareable provides methods to implement application-level advisory
       locking of the shared data structures.  These methods are called
       shlock() and shunlock().	 To use them you must first get the object
       underlying the tied variable, either by saving the return value of the
       original call to tie() or by using the built-in tied() function.

       To lock a variable, do this:

	$knot = tie $sv, 'IPC::Shareable', $glue, { %options };
	...
	$knot->shlock;

       or equivalently

	tie($scalar, 'IPC::Shareable', $glue, { %options });
	(tied $scalar)->shlock;

       This will place an exclusive lock on the data of $scalar.  You can also
       get shared locks or attempt to get a lock without blocking.
       IPC::Shareable makes the constants LOCK_EX, LOCK_SH, LOCK_UN, and
       LOCK_NB exportable to your address space with the export tags ":lock",
       ":flock", or ":all".  The values should be the same as the standard
       "flock" option arguments.

	if ( (tied $scalar)->shlock(LOCK_SH|LOCK_NB) ) {
	       print "The value is $scalar\n";
	       (tied $scalar)->shunlock;
	} else {
	       print "Another process has an exlusive lock.\n";
	}

       If no argument is provided to "shlock", it defaults to LOCK_EX.	To
       unlock a variable do this:

	$knot->shunlock;

       or

	(tied $scalar)->shunlock;

       or

	$knot->shlock(LOCK_UN);	       # Same as calling shunlock

       There are some pitfalls regarding locking and signals about which you
       should make yourself aware; these are discussed in "NOTES".

       If you use the advisory locking, IPC::Shareable assumes that you know
       what you are doing and attempts some optimizations.  When you obtain a
       lock, either exclusive or shared, a fetch and thaw of the data is
       performed.  No additional fetch/thaw operations are performed until you
       release the lock and access the bound variable again.  During the time
       that the lock is kept, all accesses are perfomed on the copy in program
       memory.	If other processes do not honor the lock, and update the
       shared memory region unfairly, the process with the lock will not be in
       sync.  In other words, IPC::Shareable does not enforce the lock for
       you.

       A similar optimization is done if you obtain an exclusive lock.
       Updates to the shared memory region will be postponed until you release
       the lock (or downgrade to a shared lock).

       Use of locking can significantly improve performance for operations
       such as iterating over an array, retrieving a list from a slice or
       doing a slice assignment.

REFERENCES
       When a reference to a non-tied scalar, hash, or array is assigned to a
       tie()d variable, IPC::Shareable will attempt to tie() the thingy being
       referenced[4].  This allows disparate processes to see changes to not
       only the top-level variable, but also changes to nested data.  This
       feature is intended to be transparent to the application, but there are
       some caveats to be aware of.

       First of all, IPC::Shareable does not (yet) guarantee that the ids
       shared memory segments allocated automagically are unique.  The more
       automagical tie()ing that happens, the greater the chance of a
       collision.

       Secondly, since a new shared memory segment is created for each thingy
       being referenced, the liberal use of references could cause the system
       to approach its limit for the total number of shared memory segments
       allowed.

OBJECTS
       IPC::Shareable implements tie()ing objects to shared memory too.	 Since
       an object is just a reference, the same principles (and caveats) apply
       to tie()ing objects as other reference types.

DESTRUCTION
       perl(1) will destroy the object underlying a tied variable when then
       tied variable goes out of scope.	 Unfortunately for IPC::Shareable,
       this may not be desirable: other processes may still need a handle on
       the relevant shared memory segment.  IPC::Shareable therefore provides
       an interface to allow the application to control the timing of removal
       of shared memory segments.  The interface consists of three methods -
       remove(), clean_up(), and clean_up_all() - and the destroy option to
       tie().

       destroy option
	   As described in "OPTIONS", specifying the destroy option when
	   tie()ing a variable coerces IPC::Shareable to remove the underlying
	   shared memory segment when the process calling tie() exits
	   gracefully.	Note that any related shared memory segments created
	   automagically by the use of references will also be removed.

       remove()
	    (tied $var)->remove;

	   Calling remove() on the object underlying a tie()d variable removes
	   the associated shared memory segment.  The segment is removed
	   irrespective of whether it has the destroy option set or not and
	   irrespective of whether the calling process created the segment.

       clean_up()
	    IPC::Shareable->clean_up;

	   This is a class method that provokes IPC::Shareable to remove all
	   shared memory segments created by the process.  Segments not
	   created by the calling process are not removed.

       clean_up_all()
	    IPC::Shareable->clean_up_all;

	   This is a class method that provokes IPC::Shareable to remove all
	   shared memory segments encountered by the process.  Segments are
	   removed even if they were not created by the calling process.

EXAMPLES
       In a file called server:

	#!/usr/bin/perl -w
	use strict;
	use IPC::Shareable;
	my $glue = 'data';
	my %options = (
	    create    => 'yes',
	    exclusive => 0,
	    mode      => 0644,
	    destroy   => 'yes',
	);
	my %colours;
	tie %colours, 'IPC::Shareable', $glue, { %options } or
	    die "server: tie failed\n";
	%colours = (
	    red => [
		'fire truck',
		'leaves in the fall',
	    ],
	    blue => [
		'sky',
		'police cars',
	    ],
	);
	((print "server: there are 2 colours\n"), sleep 5)
	    while scalar keys %colours == 2;
	print "server: here are all my colours:\n";
	foreach my $c (keys %colours) {
	    print "server: these are $c: ",
		join(', ', @{$colours{$c}}), "\n";
	}
	exit;

       In a file called client

	#!/usr/bin/perl -w
	use strict;
	use IPC::Shareable;
	my $glue = 'data';
	my %options = (
	    create    => 0,
	    exclusive => 0,
	    mode      => 0644,
	    destroy   => 0,
	    );
	my %colours;
	tie %colours, 'IPC::Shareable', $glue, { %options } or
	    die "client: tie failed\n";
	foreach my $c (keys %colours) {
	    print "client: these are $c: ",
		join(', ', @{$colours{$c}}), "\n";
	}
	delete $colours{'red'};
	exit;

       And here is the output (the sleep commands in the command line prevent
       the output from being interrupted by shell prompts):

	bash$ ( ./server & ) ; sleep 10 ; ./client ; sleep 10
	server: there are 2 colours
	server: there are 2 colours
	server: there are 2 colours
	client: these are blue: sky, police cars
	client: these are red: fire truck, leaves in the fall
	server: here are all my colours:
	server: these are blue: sky, police cars

RETURN VALUES
       Calls to tie() that try to implement IPC::Shareable will return true if
       successful, undef otherwise.  The value returned is an instance of the
       IPC::Shareable class.

AUTHOR
       Benjamin Sugars <bsugars@canoe.ca>

NOTES
   Footnotes from the above sections
       1.  If GLUE is longer than 4 characters, only the 4 most significant
	   characters are used.	 These characters are turned into integers by
	   unpack()ing them.  If GLUE is less than 4 characters, it is space
	   padded.

       2.  IPC::Shareable provides no pre-set limits, but the system does.
	   Namely, there are limits on the number of shared memory segments
	   that can be allocated and the total amount of memory usable by
	   shared memory.

       3.  If the process has been smoked by an untrapped signal, the binding
	   will remain in shared memory.  If you're cautious, you might try

	    $SIG{INT} = \&catch_int;
	    sub catch_int {
		die;
	    }
	    ...
	    tie $variable, IPC::Shareable, 'data', { 'destroy' => 'Yes!' };

	   which will at least clean up after your user hits CTRL-C because
	   IPC::Shareable's END method will be called.	Or, maybe you'd like
	   to leave the binding in shared memory, so subsequent process can
	   recover the data...

       4.  This behaviour is markedly different from previous versions of
	   IPC::Shareable.  Older versions would sometimes tie() referenced
	   thingies, and sometimes not.	 The new approach is more reliable (I
	   think) and predictable (certainly) but uses more shared memory
	   segments.

   General Notes
       o   When using shlock() to lock a variable, be careful to guard against
	   signals.  Under normal circumstances, IPC::Shareable's END method
	   unlocks any locked variables when the process exits.	 However, if
	   an untrapped signal is received while a process holds an exclusive
	   lock, DESTROY will not be called and the lock may be maintained
	   even though the process has exited.	If this scares you, you might
	   be better off implementing your own locking methods.

	   One advantage of using "flock" on some known file instead of the
	   locking implemented with semaphores in IPC::Shareable is that when
	   a process dies, it automatically releases any locks.	 This only
	   happens with IPC::Shareable if the process dies gracefully.	The
	   alternative is to attempt to account for every possible calamitous
	   ending for your process (robust signal handling in Perl is a source
	   of much debate, though it usually works just fine) or to become
	   familiar with your system's tools for removing shared memory and
	   semaphores.	This concern should be balanced against the
	   significant performance improvements you can gain for larger data
	   structures by using the locking mechanism implemented in
	   IPC::Shareable.

       o   There is a program called ipcs(1/8) (and ipcrm(1/8)) that is
	   available on at least Solaris and Linux that might be useful for
	   cleaning moribund shared memory segments or semaphore sets produced
	   by bugs in either IPC::Shareable or applications using it.

       o   This version of IPC::Shareable does not understand the format of
	   shared memory segments created by versions prior to 0.60.  If you
	   try to tie to such segments, you will get an error.	The only work
	   around is to clear the shared memory segments and start with a
	   fresh set.

       o   Iterating over a hash causes a special optimization if you have not
	   obtained a lock (it is better to obtain a read (or write) lock
	   before iterating over a hash tied to Shareable, but we attempt this
	   optimization if you do not).	 The fetch/thaw operation is performed
	   when the first key is accessed.  Subsequent key and and value
	   accesses are done without accessing shared memory.  Doing an
	   assignment to the hash or fetching another value between key
	   accesses causes the hash to be replaced from shared memory.	The
	   state of the iterator in this case is not defined by the Perl
	   documentation.  Caveat Emptor.

CREDITS
       Thanks to all those with comments or bug fixes, especially

	Maurice Aubrey	    <maurice@hevanet.com>
	Stephane Bortzmeyer <bortzmeyer@pasteur.fr>
	Doug MacEachern	    <dougm@telebusiness.co.nz>
	Robert Emmery	    <roberte@netscape.com>
	Mohammed J. Kabir   <kabir@intevo.com>
	Terry Ewing	    <terry@intevo.com>
	Tim Fries	    <timf@dicecorp.com>
	Joe Thomas	    <jthomas@women.com>
	Paul Makepeace	    <Paul.Makepeace@realprogrammers.com>
	Raphael Manfredi    <Raphael_Manfredi@pobox.com>
	Lee Lindley	    <Lee.Lindley@bigfoot.com>
	Dave Rolsky	    <autarch@urth.org>

BUGS
       Certainly; this is beta software. When you discover an anomaly, send an
       email to me at bsugars@canoe.ca.

SEE ALSO
       perl(1), perltie(1), Storable(3), shmget(2), ipcs(1), ipcrm(1) and
       other SysV IPC man pages.

perl v5.14.2			  2012-10-13		   IPC::Shareable(3pm)
[top]

List of man pages available for Kali

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net