Re^3: Global Variables Not Acting Global (FCGI)

here a simple example of a persistent variable $count while using CGI::Fast

use strict;
use warnings;
use CGI::Fast;
 
our $count = 0;
 
while ( my $q = new CGI::Fast ) {
    $count++;
    print $q->header( "text/plain" ),
          "You are request number $count. Have a good day!\n";
}
[download]

(taken from O'Reilly's CGI book and modernized )

Cheers Rolf

Comment on Re^3: Global Variables Not Acting Global (FCGI) Select or Download Code

Replies are listed 'Best First'.
Re^4: Global Variables Not Acting Global (FCGI) by Eliya (Vicar) on Apr 21, 2011 at 13:01 UTC
I think it's worth noting that for this to work reliably, you'd have to make sure that the web server side end of FastCGI (such as mod_fcgi, mod_fastcgi) is configured to run only one instance of the respective process. Otherwise, different requests could happen to be routed to different processes, which would produce unexpected results. Not to mention the confusion that would result from different people using the same CGI program and state variables. The same problem would also occur with several apache/mod_perl instances running... In other words, the easiest (and proper) way to achieve persistence across requests is to use sessions (CGI::Session), which makes your data being stored/retrieved independently of the process handling the current request.	[reply]
Re^5: Global Variables Not Acting Global (FCGI) by Anonymous Monk on Apr 22, 2011 at 01:22 UTC
In other words, the easiest (and proper) way to achieve persistence across requests is to use sessions (CGI::Session), which makes your data being stored/retrieved independently of the process handling the current request. Yup, global variables should be used to cache data or expensive objects like DBI handles, not for maintaining state	[reply]
Re^5: Global Variables Not Acting Global (FCGI) by LanX (Saint) on Apr 21, 2011 at 13:06 UTC
> I think it's worth noting ... indeed! :) Update: AFAIK one process per script is the default. Cheers Rolf	[reply]