ipc::shareable(3)

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 unavailable0;
(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 mem
ory 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 arbi
trarily 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 charac ter 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 $vari able 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 com plexity 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-depen dent).
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 "fea
ture" 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() cre ate 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 pro
cess 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 applicationlevel 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 origi
nal call to tie() or by using the built-in tied() func tion.

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 $scalar0;
(tied $scalar)->shunlock;; } else {
print "Another process has an exlusive lock.0;; }
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 dis cussed in "NOTES".
If you use the advisory locking, IPC::Shareable assumes that you know what you are doing and attempts some opti mizations. 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 pro cesses 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 post poned 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 dis
parate 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 refer
ences 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 mem
ory 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 pro
cesses may still need a handle on the relevant shared mem
ory segment. IPC::Shareable therefore provides an inter
face 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 automagi
cally by the use of references will also be removed.
rreemmoovvee(()): (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.
cclleeaann__uupp(()): IPC::Shareable->clean_up;
This is a class method that provokes IPC::Shareable to remove all shared memory segments created by the pro cess. Segments not created by the calling process are not removed.
cclleeaann__uupp__aallll(()): 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 failed0;; %colours = (
red => [
'fire truck',
'leaves in the fall',

],
blue => [

'sky',
'police cars',

],; );
((print "server: there are 2 colours0), sleep 5)
while scalar keys %colours == 2;; print "server: here are all my colours:0;
foreach my $c (keys %colours) {
print "server: these are $c: ",
join(', ', @{$colours{$c}}), "0;

}
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 failed0;

foreach my $c (keys %colours) {

print "client: these are $c: ",
join(', ', @{$colours{$c}}), "0;

}
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 vari
ables 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 auto
matically releases any locks. This only happens with
IPC::Shareable if the process dies gracefully. The
alternative is to attempt to account for every possi
ble 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 mecha
nism 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 mem
ory. 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 docu
mentation. 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.

docs.sk

comprehensive documentation repository

See also