in reply to Re^4: CGI and persistent data
in thread CGI and persistent data

Woah, bad perl-fu going on there. I can't see it working, at least not in any concievably portable way. The /dev/shm method gives you access at the speed of memory; why try to roll your own?

As an alternate suggestion, if you really do want to code something yourself instead of using the previously suggested CGI::Application::Plugin::Session -- Try using FastCGI. You gain persistence of your program, so you can just use standard Perl variables to store session info.

$,=' ';$\=',';$_=[qw,Just another Perl hacker,];print@$_;

Replies are listed 'Best First'.
Re^6: CGI and persistent data
by astroboy (Chaplain) on Sep 01, 2009 at 00:26 UTC
    I'm not clear how FastCGI works in this case. Can you provide a code example?
[reply]

      Unfortunately, I haven't used FastCGI myself, so I can't produce code, but my understanding of the process is this: A FastCGI program runs persistently, handling its own forking, and communicates with the Web server over a socket. A regular CGI app is run from scratch every time it is invoked, but a FastCGI is already running (and can have its own objects in memory) when the Web server hands of a request to it. See FastCGI for more info, and check FastCGI for modules.

      print pack("A25",pack("V*",map{1919242272+$_}(34481450,-49737472,6228,0,-285028276,6979,-1380265972)))
[reply]
[d/l]
        I'm not sure this will solve the OP's problem. If the FastCGI program saves its state to some global variables between requests, the next request might be from a different user. I think you'll still need to maintain session state that will be tied to a specific user
[reply]

In Section Seekers of Perl Wisdom