Re: mod_perl v2 Forking
Eric Frazier wrote: ... But then I found I was using 5.8.. Thanks to a guy on comp.lang.perl.misc I know that there is a change in how signals are handled, they call it deferred signal handling because Perl now is suppose to wait until the Interpeter is in a safe state. As I understand it this might avoid some things like core dumps or other errors related to dieing while trying to do something besides dieing. Mostly, yes. Look at the perldelta manpage that is distributed with perl 5.8.0, section Safe Signals. If you want to restore the 5.6-ish unsafe signal handling, this is not possible with 5.8.0 :(. But, as it has been acknowledged that this unsafe behaviour is desirable in some cases, it will be possible with perl 5.8.1. You can grab a 5.8.1 release candidate 4 from CPAN : http://search.cpan.org/~jhi/ (RC5 should be out in a few days) and see with it if using unsafe signal handlers solves your problem. You can enable them with the PERL_SIGNALS environment variable. Here's the relevant part of the perlrun manpage that comes with perl 5.8.1 RC4 : =item PERL_SIGNALS In Perls 5.8.1 and later. If set to Cunsafe the pre-Perl-5.8.0 signals behaviour (immediate but unsafe) is restored. If set to Csafe the safe (or deferred) signals are used. See Lperlipc/Deferred Signals (Safe signals). HTH.
Re: AIX perfomance
Ged Haywood wrote: Hi there, On Fri, 12 Sep 2003, Rafael Garcia-Suarez wrote: we're porting on AIX (4.3.3 and 5.2.0). The AIX boxes are supposed to be more powerful than their Linux equivalents, however the application is strangely slow on AIX You don't give much to go on. Are they really more powerful? What does 'powerful' mean anyway? What discs do you have and what interfaces do they use, how much memory, what processors, speeds, how many mod_perl processes, how big are they, are you getting into swap, etc...? Well, it's difficult to compare very different hardware, but basically the AIX boxen have SCSI discs, more memory, etc. and they're a lot more expensive ;-) Have you benchmarked some simple things on the boxes? Benchmarking simple CPU-intensive perl scripts shows that they tend to be consistently slower in user time on AIX. Moreover if I survey CPU/memory usage on Linux and AIX (resp. with top and vmstat / w) I see that the application doesn't swap memory and that the load averages remains 0.10. So I'm asking for the common wisdom about performance issues on AIX. I don't know anything worth writing about AIX but I'd look a little deeper into what you're doing before you start blaming the OS. Currently the perl I use is built with gcc and default settings. Should I set -Dusemymalloc=y ? Should I use the xlC or vac compilers ? Should I port everything to mod_perl 2 ? To all those questions at this stage, my answer would be 'I doubt it'. Find out about your systems first. There are lots of tools to help you do that. Start by checking the relevant sections of the Guide for more information about performance and benchmarking. (Or look at the little disc activity light. :) Thanks, I'll dig deeper.
Re: leaks with Apache::Request?
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 behavior (Apache/1.3.26 (Unix) mod_perl/1.27 perl@17440) with a modified version of your code (it doesn't work as is.) HTH.
Re: Exporter variables get lost
Viljo Marrandi actually wrote:
my $r = shift;
use vars qw( $log );
$log = $r-log();
if ( $some_case eq 'true' ) {
use Sub::First qw( $log );
I haven't tested, but this doesn't look as a good idea.
I don't think your code does what you think it does
(or what you think it should do.) Moreover I don't
know what this actually does (or should do) precisely.
Exporter essentially does this:
*Site::log = \$Sub::First::log;
and vars essentially does this:
*Site::log = \$Site::log;
And this symbol table manipulation occurs at compile-time,
before your code is run (without scoping effecs).
In other words don't do that.
--
Rafael Garcia-Suarez
Re: Best compile options for perl 5.8 for mod_perl 1.x and 2.x
Steven Lembark wrote: Also worth using large file support if you habitually munge 2GB files. Which is the default on linux. -- Rafael Garcia-Suarez
Re: HTML::Entities chokes on XML::Parser strings
John Siracusa wrote:
I ran into this problem during mod_perl development, and I'm posting it to
this list hoping that other mod_perl developers have dealt with the same
thing and have good solutions :)
I did ;-)
I've found that strings collected while processing XML using XML::Parser do
not play nice with the HTML::Entities module. Here's the sample program
illustrating the problem:
#!/usr/bin/perl -w
use strict;
use HTML::Entities;
use XML::Parser;
my $buffer;
my $p = XML::Parser-new(Handlers = { Char = \xml_char });
my $xml = '?xml version=1.0 encoding=iso-8859-1?test' .
chr(0xE9) . '/test';
$p-parse($xml);
print encode_entities($buffer), \n;
sub xml_char
{
my($expat, $string) = _;
$buffer .= $string;
}
The output unfortunately looks like this:
Atilde;copy;
Which makes very little sense, since the correct entity for 0xE9 is:
eacute;
That's an XML::Parser issue.
XML::Parser gives UTF-8 to your Char handler, as specified in the manpage :
Whatever the encoding of the string in the original document,
this is given to the handler in UTF-8.
The workaround I used is to write the handler like this :
sub xml_char
{
my ($expat) = _;
$buffer .= $expat-original_string;
}
Reading the original string, no need to convert UTF-8 back to iso-8859-1.
My current work-around is to run the buffer through a (lossy!?) pack/unpack
cycle:
my $buffer2 = pack(C*, unpack(U*, $buffer));
print encode_entities($buffer2), \n;
This works and prints:
eacute;
I hope it is not lossy when using iso-8859-1 encoding, but I'm guessing it
will maul UTF-8 or UTF-16. This seems like quite an evil hack.
So, what is the Right Thing to do here? Which module, if any, is at fault?
Is there some combination of Perl Unicode-related use statements that will
help me here? Has anyone else run into this problem?
-John
--
Rafael Garcia-Suarez
Bug in Apache::Session::Lock::File::clean()
Sorry if this is already known, or if I'm posting to the wrong
people, (I'm new to the mod_perl world), but :
Looks like there's a minor bug in Apache::Session::Lock::File::clean().
Patch : (against version 1.01, in distribution Apache-Session-1.54)
(also adding proper local()ization of handles)
--- Apache/Session/Lock/File.pm.origSat Sep 2 00:21:17 2000
+++ Apache/Session/Lock/File.pm Thu Apr 25 15:45:18 2002
-129,11 +129,14
my $now = time();
+local *DIR;
+local *FH;
+
opendir(DIR, $dir) || die $!;
my files = readdir(DIR);
foreach my $file (files) {
if ($file =~ /^Apache-Session.*\.lock$/) {
-if ((stat($dir.'/'.$file))[8] - $now = $time) {
+if ($now - (stat($dir.'/'.$file))[8] = $time) {
open(FH, +$dir/.$file) || next;
flock(FH, LOCK_EX) || next;
unlink($dir.'/'.$file) || next;
End of Patch.
--
Rafael Garcia-Suarez -- http://rgarciasuarez.free.fr/
http://lyon.pm.org/ -- http://cpan.org/authors/id/R/RG/RGARCIA/
-- http://use.perl.org/~rafael/
