dougm 2002/07/10 19:06:11
Modified:src/modules/perl mod_perl.c
Log:
fix for non-ithread perls
Revision ChangesPath
1.131 +1 -1 modperl-2.0/src/modules/perl/mod_perl.c
Index: mod_perl.c
===
On Mon, 8 Jul 2002 00:24:30 -0500 (CDT), Randy Kobes wrote:
Hi,
I've placed an updated perl-5.6.1/Apache-1.3.26/mod_perl-1.27
Win32 binary package, perl-win32-bin-0.8.exe (a self-extracting
archive), in ftp://theoryx5.uwinnipeg.ca/pub/other/. This
I've update configure-apache.pl to match. See:
Joe Schaefer [EMAIL PROTECTED] writes:
[...]
Somehow the assignment operator MUST be involved in the leak here.
(You only get a leak when the *same* reference (*SV) is on both sides
of the assignment).
Could someone with modperl 1.2x built using a perl 5.8 release candidate
please test
On Wed, 10 Jul 2002, Fran Fabrizio wrote:
Just to confirm, the end result of Matt's slide presentation was that
Error.pm was good, and you should use it, but you should not use the
try/catch syntax, or at the bare minimum only catch in your outermost
handler. Is that correct? We were
Joe Schaefer wrote:
Somehow the assignment operator MUST be involved in the leak here.
(You only get a leak when the *same* reference (*SV) is on both sides
of the assignment).
Could someone with modperl 1.2x built using a perl 5.8 release candidate
please test this out:
I got the same
Does anyone know what's causing the Apache::Request object to
leak here? See # XXX comment below:
Perl
package Apache::test;
sub Apache::Request::DESTROY{warn DEAD: $_[0]\n}
sub Apache::DESTROY{warn Dead: $_[0]\n}
use Devel::Peek;
use Apache::Request;
sub
Matt Sergeant wrote:
On Wed, 10 Jul 2002, Fran Fabrizio wrote:
Just to confirm, the end result of Matt's slide presentation was that
Error.pm was good, and you should use it, but you should not use the
try/catch syntax, or at the bare minimum only catch in your outermost
handler. Is that
Kent, Mr. John wrote:
Greetings,
Have noticed that modperl-2.0 servers running on Solaris 2.7 start
off at 23M in size. Five hours later they were at 38M. If allowed to
continue
they could eventually use up all available RAM and crash the system.
Stopping then restarting returned
Stas Bekman wrote:
If you are talking about threaded mpms, we will need to develop new
tools to restrict the size of the perl interpreters in the pool.
I was thinking about that too. Are there hooks for causing an
interpreter to exit? Is it safe to simply call CORE::exit? I'd like to
use CGI::Carp qw(fatalsToBrowser); was having no effect on my modules.
Changing a line in CGI::Carp
sub ineval { $^S || _longmess() =~ /eval [\{\']/m }
---
sub ineval { _longmess() =~ /eval [\{\']/m }
,by advise from a mail I found in archives from last year, produced the
results that I was
I think I made a mistake posting this query over the holiday weekend, so I'm
gonna speak up again.
I have a couple of strange bugs showing up in Bricolage that have something
to do with Apache-print timing out (with Win 95 and Mac OS 9 -- yes, these
folks need to join the new millennium), and
[resent to modperl list; earlier copy mistakenly cc'd to p5p]
Does anyone know what's causing the Apache::Request object to
leak here? See # XXX comment below:
Perl
package Apache::test;
sub Apache::Request::DESTROY{warn DEAD: $_[0]\n}
sub Apache::DESTROY{warn Dead: $_[0]\n}
just upgraded from 1.3.22/mod_perl 1.26 to 1.3.26/1.27 and while all
the other stuff is working fine my daemon does not recognize the
Perl-directive anymore !?
test in httpsd.conf:
Perl
my $test=hans;
/Perl
# /usr/local/apache/bin/httpsdctl start
Syntax error on line 105 of
Perrin Harkins wrote:
Stas Bekman wrote:
If you are talking about threaded mpms, we will need to develop new
tools to restrict the size of the perl interpreters in the pool.
I was thinking about that too. Are there hooks for causing an
interpreter to exit? Is it safe to simply
Stas Bekman wrote:
I think the idea was to have a special thread running whose only purpose
is monitoring the pool of idle interpreters.
That sounds like a better solution.
I believe that we can add a Perl space hook that sets a flag that
condemns an interpreter to death.
The other
Perrin Harkins wrote:
Stas Bekman wrote:
I think the idea was to have a special thread running whose only purpose
is monitoring the pool of idle interpreters.
That sounds like a better solution.
The drawback is that there will be two different solutions for threaded
and preforked
Perl
my $test=hans;
/Perl
Don't you also need
PerlModule Apache::PerlSections
Maybe?
xoxo,
Andy
--
'Andy Lester[EMAIL PROTECTED]
Programmer/author petdance.com
Daddy parsley.org/quinn Jk'=~/.+/s;print((split//,$)
Andy Lester wrote:
Perl
my $test=hans;
/Perl
Don't you also need
PerlModule Apache::PerlSections
Maybe?
that shouldn't be required. my guess is that EVERYTHING=1 was not
specified in the upgrade build procedure.
check /perl-status?hooks and make sure that PerlSections is
On Wed, 10 Jul 2002, Perrin Harkins wrote:
Matt Sergeant wrote:
On Wed, 10 Jul 2002, Fran Fabrizio wrote:
Just to confirm, the end result of Matt's slide presentation was that
Error.pm was good, and you should use it, but you should not use the
try/catch syntax, or at the bare minimum only
On Wed, 10 Jul 2002, Matt Sergeant wrote:
Ah, in that case I'm recommending Dave's stuff. It's more flexible and
doesn't use that irritating -param stuff. Though I have to do a little
more research to be certain some things are possible (like turning on
stack traces globally).
Actually,
Internet Software Engineer (PERL)
About Web Services is seeking an Internet Software Engineer to maintain and
develop new applications for it's hosting platform. About Web Services is a
division of About.com that provides hosting solutions to more than 4 million
web sites including
Hey All,
I'm getting this error when I try to make mod_perl2, under solaris 9
make
cd src/modules/perl make -f Makefile.modperl
make[1]: Entering directory `/usr/share/src/modperl-2.0/src/modules/perl'
gcc -I/usr/share/src/modperl-2.0/src/modules/perl
-I/usr/share/src/modperl-2.0/xs
Changing a line in CGI::Carp
sub ineval { $^S || _longmess() =~ /eval [\{\']/m }
---
sub ineval { _longmess() =~ /eval [\{\']/m }
Are there any solutions to this problem that don't involve changing
CGI::Carp? Perhaps I should just rip the code that I want out of CGI::Carp?
Why not just
I went through this recently
set $apr = Apache::Registry-instance($r) rather than -new($r);
-Original Message-
From: Tim Sebastian Böckers [mailto:[EMAIL PROTECTED]]
Sent: 28 June 2002 18:44
To: [EMAIL PROTECTED]
Subject: param trouble
dear list,
i run into some trouble
Is there any easy way to check which options were used to compile mod_perl.
Or more specifically, is there an easy way to check which type handlers a
mod_perl build allows, if it allows stacked handlers, if it allows method
handlers and if it allows perl sections? Thanks.
--
Eric L. Brine
Eric L. Brine wrote:
Is there any easy way to check which options were used to compile mod_perl.
Or more specifically, is there an easy way to check which type handlers a
mod_perl build allows, if it allows stacked handlers, if it allows method
handlers and if it allows perl sections? Thanks.
26 matches
Mail list logo
