If you are working in a UNIX environment you may be able to make use of message queues. Message queues allow one application to talk to another using memory.
Basically, what you would need to do is:
1. Write a program that will create N message queues (with the appropriate permissions and uid/gid) equivalent to the number of files that you need. Also make sure that the program writes the message queue IDs to a file so that your CGI app can read them.
2. Run the program once to create the message queues.
3. Write your CGI application such that it reads the message queue ID(s) from disk and uses them to write/read to the message queue(s). Note: That you'll still have to come up with a way to lock a message queue to a particular CGI process otherwise you will have CGI processes that will be trying to use another process' message queue.
4. Assuming that you have this setup correctly, you could have one CGI process write to a message queue and another or even the same CGI process read from that queue.
In this fashion, you would be using message queues to act as files and not have to write to disk.
The relevant perl functions that you would want to use are shmget, shmwrite, shmread and shmctl. You can read more about this on page 346 of the Camel book. Also the book recommends trying the IPC::SysV module from CPAN.
There are, of course, limitations in using this type of shared memory in that, I believe, that once you pop the data off of the message queue that it is gone and unavailable for other processes to read. Sort of a write once, read once system.
metadoktor
"The doktor is in." |