On Oct 11, 10:25*am, Jean <alertj...@gmail.com> wrote:
> I am searching for efficient ways of communication across two Perl
> scripts. I have two scripts; Script 1 generates some data. I want my
> script two to be able to access that information.
> There is no guarantee that Script 2 will be run after Script 1. So
> there should be some way to free that memory using a watchdog timer.
It sounds like there's no guarantee that either script will overlap
while running, either. Unless you write your data to a file on disk,
you'll need another program to act as some sort of broker to manage
the data you want to share.
You could try using a third-party broker, or perhaps use an SQL
database to store your data. ...or you could just write what you want
to share to disk, to be picked up by Script 2.
> The easiest/dumbest way is to write the data generated by
> script 1 as a file and read it later using script 2.
That may be easiest, but I don't think it's the dumbest. And if
you use this approach, I highly recommend using the "Storable" module
(it's a standard module so you should already have it). If you have a
reference to data in Script 1 (for example, $dataReference), you can
save it in one line (if you don't count the "use Storable" line), like
this:
use Storable qw(lock_nstore lock_retrieve);
lock_nstore($dataReference, "file_name");
and then Script 2 can read it in with one line like this:
use Storable qw(lock_nstore lock_retrieve);
my $dataReference = lock_retrieve("file_name");
Now Script 1 and Script 2 should both have a $dataReference that
refers to identical data.
Type "perldoc Storable" at the Unix/DOS prompt to read more about
this module.
It's hard to get much simpler than this. You might be tempted to
write your own file-writing and file-reading code, but if you do,
you'll have to handle your own file locking and your own to/from file
stream conversions. (And that'll probably take more than just two
lines of code to implement.)
If you're good with SQL, you may want to try a DBI module like
DBD::SQLite. The database for SQLite is stored on disk (so you don't
need a third-party program to manage the data), and it gives you the
flexibility in that if you ever have move your shared data to a
database server, most of the data-sharing code will remain unchanged.
Also, don't forget to "use strict;" and "use warnings;" if you
aren't using them already; they'll save you lots of headaches in the
long run.
I hope this helps,
-- Jean-Luc
Similar Threads
