views:

89

answers:

2

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 2 to be able to access that information.

The easiest/dumbest way is to write the data generated by Script 1 as a file and read it later using Script 2. Is there any other way than this? Can I store the data in memory and make it available to Script 2 (of course with support from my Linux )? Meaning malloc some data by Script 1 and make Script 2 able to access it.

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.

Let me reveal some more context. I am running these scripts on a web-server using CGI-Perl. So at the click of a button Script 1 is run and it generates a html web-page. Now the user can add some inputs to to this generated web-page and click a button on this new page.Now Script 2 should be able to read the data on new web-page.I can post the data back to web-server again but a more efficient way is to keep a copy of generated page in server also and make it available to script 2. Now, I would like to avoid writing down the generated page as a file. I was thinking of storing it in memory


Let me reveal some more context. I am running these scripts on a web-server using CGI-Perl. So at the click of a button Script 1 is run and it generates a html web-page. Now the user can add some inputs to to this generated web-page and click a button on this new page.Now Script 2 should be able to read the data on new web-page.I can post the data back to web-server again but a more efficient way is to keep a copy of generated page in server also and make it available to script 2. Now, I would like to avoid writing down the generated page as a file. I was thinking of storing it in memory

+1  A: 

This depends somewhat on your usage... one large set of data? Many small messages? Di you canre at all about data persistance? Is it TOTALLY asynchronous?

Some of the options are:

  • For any but the most high performace web sites, the best approach is to write our the HTML pages to files!. Unless the intrer-process communication is benchmarked to be the botttleneck in performance, don't both with any of the non-file solutions (shared memory, cache, intermediate server).

  • Specifically for two CGI scripts on the same server, if you run them under mod_perl or some other arrangement which shares Perl interpreter between 2 CGI processes, you can develop a package to serve as cache, which -with its package level variable - would be preserved in memory by mod_perl as long as mod_perl is running and can thus be used by a writer CGI process and a reader CGI process to communicate. Of course the usual synchronization/deadlock and persistance issues associated with reader/writer need to be considered.

    As an alternative, use Apache::Session sessions to store inter-session data.

  • As you noted, shared memory. For example use IPC::ShareLite, IPC::Cache, or this solution from perlmonks.

    Also, please check Chapter 16 Recipe 12 "Sharing Variables in Different Processes" from O'Reilly's "Perl Cookbook" (no link since non-pirated versions aren't online anywhere I know of)

  • Use a permanent medium. A file is one option. A database is another.

  • For async, use an intermediate messaging system (MQ, Tibco, something more lightweight). Probably a bit of an overkill in this scenario but a valid option to be aware of. This one is likely to be pretty stablem solid and optmized, but possibly not free and less flexible/tailored.

  • Or roll your own simple messaging system server - it's not THAT complicated for very simple one you seem to need.

    Listen on one port for requests from first process to store data, listen on another port for requests from consumer process to send you that data, store the data in a storage area in memory and purge it when it expires using alarms or separate watcher child process).

DVK
And Yeah..they are totally asynchronous. Data is substantially large. It is not many small messages. They are "infrequent large messages".
alertjean
Clarify your question. Don't hide that info in comments.
brian d foy
Added CGI-specific answer.
DVK
+1  A: 

You've tagged your question as "cgi". Are they both CGI programs? In that case, they can just talk to each other by making HTTP requests.

However, you'll have to tell a lot more about why you are trying to do this and what you need to accomplish for us to help you. It's certainly easy for Perl programs to communicate with each other in some fashion, but that doesn't mean it's the right answer for you.

When you have complex requirements for interaction among CGI programs, you probably want to move to a web framework that handles a lot of those details for you. Catalyst might be where'd you want to start. There's even a book for it.

brian d foy
With proper templating and session management, you don't need to do any of that.
brian d foy
"With proper templating and session management" Could you please explain more about it ? Or somewhere I can read about it. Its my first time writing a CGI-Perl application.
alertjean
There are lots of books, etc. It's a big subject. Google is good. It sounds like you probably want a web framework, such as Catalyst.
brian d foy