You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Randal L. Schwartz" <me...@stonehenge.com> on 2001/04/12 05:22:38 UTC
from the "quick hacks" department... x-bit controls mod_cgi
In an .htaccess, I place:
Options +ExecCGI
PerlFixupHandler "sub { -f $_[0]->filename and -x _ and $_[0]->handler(q{cgi-script}) }"
Now any executable file in this directory (or below) is processed with
mod_cgi. Any non-executable file is processed with whatever the MIME
engine came up with before.
OK, too cool to not pass on. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: from the "quick hacks" department... x-bit controls mod_cgi
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Tim" == Tim Bunce <Ti...@ig.co.uk> writes:
Tim> On Wed, Apr 11, 2001 at 08:22:38PM -0700, Randal L. Schwartz wrote:
>>
>> In an .htaccess, I place:
>>
>> Options +ExecCGI
>> PerlFixupHandler "sub { -f $_[0]->filename and -x _ and $_[0]->handler(q{cgi-script}) }"
>>
>> Now any executable file in this directory (or below) is processed with
>> mod_cgi. Any non-executable file is processed with whatever the MIME
>> engine came up with before.
>>
>> OK, too cool to not pass on. :)
Tim> Except that I think you'll find that string is being recompiled for
Tim> each request - slow and leaks memory. The principle is good though :)
Well, then, untested:
.htaccess:
PerlFixupHandler Stonehenge::XBitCGI
Options +ExecCGI
$INC/Stonehenge/XBitCGI.pm
sub Stonehenge::XBitCGI::handler {
-f $_[0]->filename and -x _ and $_[0]->handler(q{cgi-script});
return -1;
}
Better? :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: from the "quick hacks" department... x-bit controls mod_cgi
Posted by Perrin Harkins <pe...@elem.com>.
> Can you briefly explain why it leaks memory?
I haven't tried it, but I'm guessing it's creating a new anonymous sub on
every request.
> I have been playing with Apache::Leak and Devel::Leak trying to figure out
> what is happening when Perl code leaks memory, but I haven't got my head
> around it yet...
Most people don't get much useful information out of those modules. The
things people think of as leaks are often not really leaks, so they don't
show up with these (see below).
> Also, a more general question to the list. How reasonable is it to assume
> that most of the more standard modules on CPAN don't leak memory when used
> in a mod_perl environment?
Totally unreasonable. Most module authors have not attempted to look for
process growth over long periods of use. They may have tried to get rid of
any circular references, but that's usually about it.
Let's be clear about terminology: a real memory leak is a situation where a
program discards some memory and fails to free it or reuse it. Perl has
some of these, a few of which are documented here:
http://language.perl.com/faq/v2/Q4.19.html
Usually though, growth in size is not from a leak; it's just perl using more
memory. There are some things to be careful of that are listed in the guide
(passing large strings by value, slurping whole files into a single scalar,
etc.). Note that lexical variables do not relinquish memory when they go
out of scope, unless you manually undef them. Some growth will happen when
the child processes use variables that were in copy-on-write memory from the
parent process.
How can you tell what's going on? If you hit your module 100 times, and
then you hit it another 100 and it continues to grow, you may have an actual
leak. If it stabilizes after the first 100, you just have normal growth.
Don't expect to see growth on every hit; perl allocates memory in chunks and
only grabs another chunk when it needs one.
You can read some interesting stuff from Matt about finding memory leaks
here:
http://groups.yahoo.com/group/modperl/message/27908
http://groups.yahoo.com/group/modperl/message/27943
- Perrin
Re: from the "quick hacks" department... x-bit controls mod_cgi
Posted by Cees Hek <ce...@sitesuite.net>.
On Thu, 12 Apr 2001, Tim Bunce wrote:
> On Wed, Apr 11, 2001 at 08:22:38PM -0700, Randal L. Schwartz wrote:
> >
> > In an .htaccess, I place:
> >
> > Options +ExecCGI
> > PerlFixupHandler "sub { -f $_[0]->filename and -x _ and $_[0]->handler(q{cgi-script}) }"
> >
> > Now any executable file in this directory (or below) is processed with
> > mod_cgi. Any non-executable file is processed with whatever the MIME
> > engine came up with before.
> >
> > OK, too cool to not pass on. :)
>
> Except that I think you'll find that string is being recompiled for
> each request - slow and leaks memory. The principle is good though :)
Can you briefly explain why it leaks memory?
I have been playing with Apache::Leak and Devel::Leak trying to figure out
what is happening when Perl code leaks memory, but I haven't got my head
around it yet...
Also, a more general question to the list. How reasonable is it to assume
that most of the more standard modules on CPAN don't leak memory when used
in a mod_perl environment? For example DBI (not to pick on you Tim),
Data::Dumper, HTML::Parser or MD5 just to name some of the more common
modules. Are there any modules that I should stay away from when using
mod_perl?
- Cees Hek
Re: from the "quick hacks" department... x-bit controls mod_cgi
Posted by Tim Bunce <Ti...@ig.co.uk>.
On Wed, Apr 11, 2001 at 08:22:38PM -0700, Randal L. Schwartz wrote:
>
> In an .htaccess, I place:
>
> Options +ExecCGI
> PerlFixupHandler "sub { -f $_[0]->filename and -x _ and $_[0]->handler(q{cgi-script}) }"
>
> Now any executable file in this directory (or below) is processed with
> mod_cgi. Any non-executable file is processed with whatever the MIME
> engine came up with before.
>
> OK, too cool to not pass on. :)
Except that I think you'll find that string is being recompiled for
each request - slow and leaks memory. The principle is good though :)
Tim.