Recipe 16.12. Sharing Variables in Different Processes
Author: Tom Christiansen & Nathan Torkington
Date: 1999-07-02T01:44:07Z

#

| Chapter 16 Process Management and Communication |

## 16.12. Sharing Variables in Different Processes

### Problem

You want to share variables across forks or between unrelated processes.

### Solution

Use SysV IPC, if your operating system supports it.

### Discussion

While SysV IPC (shared memory, semaphores, etc.) isn't as widely used as pipes, named pipes, and sockets for interprocess communication, it still has some interesting properties. Normally, however, you can't expect to use shared memory via `shmget` or the mmap (2) system call to share a variable among several processes. That's because Perl would reallocate your string when you weren't wanting it to.

The CPAN module IPC::Shareable takes care of that. Using a clever `tie` module, SysV shared memory, and the Storable module from CPAN allows data structures of arbitrary complexity to be shared among cooperating processes on the same machine. These processes don't even have to be related to each other.

Example 16.11 is a simple demonstration of the module.

#### Example 16.11: sharetest

    #!/usr/bin/perl
    # sharetest - test shared variables across forks
    use IPC::Shareable;

    $handle = tie $buffer, 'IPC::Shareable', undef, { destroy => 1 };
    $SIG{INT} = sub { die "$$ dying\n" };

    for (1 .. 10) {
        unless ($child = fork) {        # i'm the child
            die "cannot fork: $!" unless defined $child;
            squabble();
            exit;
        }
        push @kids, $child;  # in case we care about their pids
    }

    while (1) {
        print "Buffer is $buffer\n";
        sleep 1;
    }
    die "Not reached";

    sub squabble {
        my $i = 0;
        while (1) {
            next if $buffer =~ /^$$\b/o;
            $handle->shlock();
            $i++;
            $buffer = "$$ $i";
            $handle->shunlock();
        }
    }

The starting process creates the shared variable, forks off 10 children, and then sits back and prints out the value of the buffer every second or so, forever, or until you hit Ctrl-C.

Because the SIGINT handler was set before any forking, it got inherited by the squabbling children as well, so they'll also bite the dust when the process group is interrupted. Keyboard interrupts send signals to the whole process group, not just one process.

What do the kids squabble over? They're bickering over who gets to update that shared variable. Each one looks to see whether someone else was here or not. So long as the buffer starts with their own signature (their PID), they leave it alone. As soon as someone else has changed it, they lock the shared variable using a special method call on the handle returned from the `tie`, update it, and release the lock.

The program runs much faster by commenting out the line that starts with `next` where each process is checking that they were the last one to touch the buffer.

The `/^$$\b/o` may look suspicious, since `/o` tells Perl to compile the pattern once only, but then went and changed the variable's value by forking. Fortunately, the value isn't locked at program compile time, but only the first time the pattern is itself compiled in each process, during whose own lifetime `$$` does not alter.

The IPC::Sharable module also supports sharing variables among unrelated processes on the same machine. See its documentation for details.

### See Also

The `semctl`, `semget`, `semop`, `shmctl`, `shmget`, `shmread`, and `shmwrite` functions in Chapter 3 of Programming Perl and in perlfunc (1); the documentation for the IPC::Shareable module from CPAN

16.11. Making a Process Look Like a File with Named Pipes |  | 16.13. Listing Available Signals