mod_perl

 view release on metacpan or  search on metacpan

Apache-Test/Changes  view on Meta::CPAN

superclass' method. [Stas]

Apache::TestRunPerl now performs an early check whether it can load
the right mod_perl environment. [William McKee <william@knowmad.com>,
Stas]

$ENV{APACHE_TEST_NO_STICKY_PREFERENCES}, if true, will both suppress
generation of persistent preferences and ignore any that already exist.
[Geoffrey Young]

make the project's test suite relocatable, handling the case where
after Apache-Test configuration was created and not cleaned up before
the directory was moved. This is especially important for those cases
where users try to run 'make test' as root from /root, A-T tells them
that they can't do that (because of the perms) and suggests to try
again, afer moving the whole project under /tmp or similar. [Stas]

When running as 'root' make the client side drop the root permissions
and run with the same permissions as the server side
(e.g. nobody). This is needed in case the client side creates any
files after the initial check (during server side startup and beyond),

Apache-Test/lib/Apache/TestRun.pm  view on Meta::CPAN

        chdir $top if $top and -d $top;
    }

    # reconstruct argv, preserve multiwords args, eg 'PerlTrace all'
    my $argv = join " ", map { /^-/ ? $_ : qq['$_'] } @ARGV;
    $orig_command = "$^X $0 $argv";
    $orig_cwd = Cwd::cwd();
    $self->set_ulimit;
    $self->set_env; #make sure these are always set

    $self->detect_relocation($orig_cwd);

    my(@argv) = @_;

    $self->getopts(\@argv);

    $self->pre_configure();

    # can't setup the httpd-specific parts of the config object yet
    $self->{test_config} = $self->new_test_config();

Apache-Test/lib/Apache/TestRun.pm  view on Meta::CPAN

}


# make it easy to move the whole distro w/o running
# 't/TEST -clean' before moving. when moving the whole package,
# the old cached config will stay, so we want to nuke it only if
# we realize that it's no longer valid. we can't just check the
# existance of the saved top_dir value, since the project may have
# been copied and the old dir could be still there, but that's not
# the one that we work in
sub detect_relocation {
    my($self, $cur_top_dir) = @_;

    my $config_file = catfile qw(t conf apache_test_config.pm);
    return unless -e $config_file;

    my %inc = %INC;
    eval { require "./$config_file" };
    %INC = %inc; # be stealth
    warn($@), return if $@;

    my $cfg = 'apache_test_config'->new;

    # if the top_dir from saved config doesn't match the current
    # top_dir, that means that the whole project was relocated to a
    # different directory, w/o running t/TEST -clean first (in each
    # directory with a test suite)
    my $cfg_top_dir = $cfg->{vars}->{top_dir};
    return unless $cfg_top_dir;
    return if $cfg_top_dir eq $cur_top_dir;

    # if that's the case silently fixup the saved config to use the
    # new paths, and force a complete cleanup. if we don't fixup the
    # config files, the cleanup process won't be able to locate files
    # to delete and re-configuration will fail

docs/user/install/install.pod  view on Meta::CPAN

C<-Dusethreads>. Remember that threads-support slows things down and
on some platforms it's unstable (e.g., FreeBSD), so don't enable it
unless you really need it.

=item 64 bit Linux

If while running C<make test> while building mod_perl 2 you get an error like
this:

  /usr/bin/ld: /usr/local/lib/perl5/5.10.1/x86_64-linux/CORE/libperl.a(op.o): \
  relocation R_X86_64_32S against `PL_sv_yes' can not be used when making a shared \
                  object; recompile with -fPIC
  /usr/local/lib/perl5/5.10.1/x86_64-linux/CORE/libperl.a: could not read symbols: Bad \
                  value

You're likely on 64 bit Linux and will need to build Perl for that platform.
You can do so by running Perl's C<Configure> with the C<$CFLAGS> environment
variable and the C<-A> and C<ccflags> options. So if you normally build Perl
with:

  % ./Configure -des

docs/user/performance/mpm.pod  view on Meta::CPAN

using specially designed for that purpose tools.

The new thing is that the core API has been spread across multiply
modules, which can be loaded only when needed (this of course works
only when mod_perl is built as DSO). This allows us to save some
memory. However the savings are not big, since all these modules are
writen in C, making them into the text segments of the memory, which
is perfectly shared. The savings are more significant at the startup
speed, since the startup time, when DSO modules are loaded, is growing
almost quadratically as the number of loaded DSO modules grows
(because of symbol relocations).

=head2 Memory Requirements in Threaded MPM

The threaded MPM is a totally new beast for mod_perl users. If you run
several processes, the same memory sharing techniques apply, but
usually you want to run as few processes as possible and to have as
many threads as possible. Remember that mod_perl 2.0 allows you to
have just a few Perl interpreters in the process which otherwise runs
multiple threads. So using more threads doesn't mean using
significantly more memory, if the maximum number of available Perl