Thomas Bätzler wrote: > Steve Bertrand <st...@ibctech.ca> asked: >> I'm writing a web interface using CGI::Application for a project that >> houses numerous methods within a dozen modules. >> >> One particular process displays a template to the user with passed in >> data, and then has four more steps before completing. The result of this >> procedure will be the modification of an elaborate data structure. The >> data structure may need to be modified along the way. >> >> Given that I can get through the web GUI portion of the process with >> just a couple of params, I'd like to find a way to retain the entire >> data structure without having to re-instantiate it (which requires >> rebuilding numerous objects etc), or pass each variable within it as a >> param on each CGI invocation. >> >> Can I, and is it plausible to create a cyclic ref redundancy of the data >> structure, store the memory location in a variable, pass the variable >> data as a param, and then recreate the data based on the variable that >> contains the memory location at the end of the entire CGI process? Is >> exploiting Perl's garbage collection like this possible, and ok to do? >> >> I'd like to be able to 'carry' the data structure without having to >> 'store' it to disk, if possible > > If you're using "standard" Perl CGI, a new interpreter is spawned for each of > your requests. At the end of each request, the interpreter exists, and it > takes any uncollected garbage with it. The next Perl process you start will > get a completely new, empty, pristine memory space without any traces of > previous use. So you can't store store data in memory between invocations > that way.
My understanding has always been that when a perl script exits, any memory that it can't free due to dangling pointers is doomed. This leaked memory is never released back to the OS, and is permanently 'saved' for future invocations of other Perl programs. Perhaps I've mis-understood something along the way. > The easiest way to have persistent data across invocations is having a > persistent Perl process and session handling. With CGI, this means using > Apache and mod_perl and possibly a toolkit/framework/whatchamaycallit like > Embperl on top. Although I have not used it yet personally, I would assume > that the jifty framework is up to the task, too. > > If you can't use mod_perl or a stand-alone jifty server and if you have a > Unix system, > http://search.cpan.org/~samtregar/IPC-SharedCache-1.3/SharedCache.pm might be > useful. I'll take a look at the various options you've specified. Thanks! However, I'm very curious to learn more about what happens when Perl leaves data in memory that it can't collect. It would be interesting to know whether leaked memory from one perl invocation can be accessed at a later time under another invocation, by using only the memory address. Steve
smime.p7s
Description: S/MIME Cryptographic Signature
