Michael Peters wrote:
Jim Albert wrote:
Lack of response on this tells me:
1. Nobody is using ModPerl::PerlRun any longer to run their scripts
under mod_perl. I doubt it.
From the docs:
This module is meant for "Dirty" CGI Perl scripts
and
The Apache::Registry handler is much faster
So new development shouldn't be targetting PerlRun anymore, but
Registry. If you are trying to work with a legacy app, then that is more
understandable.
Yes, I have a lot of old code and I don't ever see myself having enough
time to convert it to Registry, if that would in fact be better for my
situation. I've never really agreed with the "dirty" cgi perl scripts
terminology. I really consider PerlRun and Registry simply different
paradigms. With PerlRun my script itself doesn't get loaded persistently
into memory, but that's not a huge deal... perl and all the modules the
script uses do get loaded persistently so that probably accounts for 90%
of the speedup since most of my code is in underlying modules which are
mod_perl safe. To convert them to Registry to gain maybe another 10%
doesn't seem to be worth the effort. Besides the fact that if I choose
the scripts to run mod_cgi perhaps in a non mod_perl environment, then
they are all set to go. My code does run under various apache
environments so keeping it flexible is important to me.
Hopefully future mod_perl versions don't discount what I would guess is
the large amount of PerlRun code still running out there. If people have
code and it works, most don't have time to write it over to make it work
in a different way.
2. There is an alternative to CGI.pm that is mod_perl safe. If there is
a mod_perl safe alternative to CGI.pm for use under ModPerl::PerlRun
scripts for things like retrieving input from QUERY_STRING and working
with cookies, please point me to what you use for this.
Have you tried using CGI.pm in an OO fashion to see if it fixes the
problem you're having? If that doesn't work, then I'd suggest sticking
with your original thought and just do the resetting the globals
yourself at the beginning of every request.
CGI::_reset_globals();
Actually, you're partly correct. I'm sorry... I forgot to point that out
in my previous messages. I actually did have to switch to using CGI.pm
in OO via something like:
my $cgi_obj = CGI->new();
I needed to switch to this in order to have the new() method called for
each run of my cgi in the request since it is new() that calls init()
which is what reads in the request information.
However, simply switching to OO was not enough. That didn't clear out
the global variables in CGI.pm such as @QUERY_PARAM between calls to my
cgi. I wrote a method in one of my modules named NetrCGI.pm to do the
following:
sub NetrCGI_makeCGIdotPMmodPerlSafe
{
my $self = shift;
undef @CGI::QUERY_PARAM;
undef $CGI::QUERY_CHARSET;
undef %CGI::QUERY_FIELDNAMES;
}
I thought this was safer than calling CGI::initiliaze_globals since I
wasn't sure if the values of all those globals were important throughout
the use of CGI.pm, but I convinced myself that I could safely undef the
above three variables since they only seem to be used for saving state
which was the problem for me to begin with. Actually, undefing
@QUERY_PARAM would have been sufficient for my problem.
I don't think your scenario is common enough to get this put into CGI.pm
itself since it would slow down everyone else (which is why Lincoln put
it into a cleanup handler in the first place, so it's run after the
output has been sent to the browser).
Yes, and in most cases that's fine, except for (at least) the case where
the httpd process is running multiple mod_perled scripts in a single
request... for example, mutiple server side includes of the script in
the same html file.
But you may be able to convince Lincoln to make the method public and
documented so that it won't get ripped out from under you some day.
Yes, I was thinking maybe an option to the new() method to force an
immediate call to initialize_globals seems like maybe a good way to do
it. Then anyone not affected by this can simply ignore it. But, I'd
leave that open for Lincoln to decide how best to put in the hook so as
to have no impact on those not affected by this. It does look Lincoln
made an effort to keep CGI.pm mod_perl safe, so hopefully he can add in
this extra hook to keep it more mod_perl safe. I've forwarded him these
suggestions.
Alternatively, I was considering just turning on $CGI::PERLEX since this
forces a call to _reset_globals in new. However, I see this that
$CGI::PERLEX is meant to indicate ActivateState's PerlEx. I don't know
what that is or what it might indicate in future versions of CGI.pm so I
chose against turning that variable on.
# Turn on special checking for ActiveState's PerlEx
$PERLEX++ if defined($ENV{'GATEWAY_INTERFACE'}) &&
$ENV{'GATEWAY_INTERFACE'} =~ /^CGI-PerlEx/;
The hook into new() to force a _refresh_globals seems cleanest but
another global like $CGI::PERLEX that is not tied to ActiveState's
PerlEx would also work.
--
Jim Albert