[Chicago-talk] Using Storable to exchange data between 2 processes

Jay Strauss me at heyjay.com
Thu Jan 22 22:10:04 CST 2004

Steve & Greg,

I want to avoid an RDBMS.  Maybe using a DBM but what's wrong with the code
below?  Seems nice and simple, but maybe I'm missing something.  Although
I'd like to avoid a file all together.

The writer process writes maybe 200,000 times a day (guessing), but the
writes are sporadic, a couple a second then none for 5 seconds.  The reader
is an on demand service, maybe a thousandish a day


use strict;
use Storable qw(store retrieve freeze thaw);

my %data = IBM=>{last=>0};
my $s;

if (my $pid = fork) {
else {

sub parent {

        while (1) {
                sleep 2;
                my $data = retrieve('/tmp/jstrauss');
                print $data->{IBM}{last},"\n";


sub child {

        foreach (0..60) {
                sleep 1;
                $data{IBM}{last} = $_;


----- Original Message -----
From: "Steven Lembark" <lembark at wrkhors.com>
To: "Chicago.pm chatter" <chicago-talk at mail.pm.org>
Sent: Thursday, January 22, 2004 10:48 AM
Subject: Re: [Chicago-talk] Using Storable to exchange data between 2

> > From your description, perhaps a DBM file accessed by the two
> > processes would work well?  The "writer" can write records to the db
> > as they're read, and the "reader" can just open the db read-only.
> > I don't know if windows would give you "sharing violations" (bah).
> No good way to share a DBM file between proc's on hetro O/S
> boxes that I know of. Probably simpler to use message passing
> to move data structures used to init the objects. If you need
> persistence then have a master node store the permenant copies
> via tie.
> DBI might work for this. Combined with a bit of MySQL it'd
> give you a way to exchange the data over a network at the
> expense of having to glob-ify it in MySQL. You could tie a
> hash in each of the proc's to MySQL (i.e., relational instead
> of ISAM) and use DBI for your message passing via query on
> a set of passed-around keys.
> The catch is finding a reliable way to pass the keys around,
> which requires messages, which leaves messages as the most
> reasonable way to pass simple data structures around in the
> first place.
> --
> Steven Lembark                               2930 W. Palmer
> Workhorse Computing                       Chicago, IL 60647
>                                             +1 888 359 3508
> _______________________________________________
> Chicago-talk mailing list
> Chicago-talk at mail.pm.org
> http://mail.pm.org/mailman/listinfo/chicago-talk

More information about the Chicago-talk mailing list