stas 01/12/20 23:44:43
Modified: . index.html
Added: . win32_binaries.html win32_binaries.pod
win32_compile.html win32_compile.pod
win32_multithread.html win32_multithread.pod
Log:
add win32 docs by Randy Kobes
Revision Changes Path
1.97 +8 -0 modperl-site/index.html
Index: index.html
===================================================================
RCS file: /home/cvs/modperl-site/index.html,v
retrieving revision 1.96
retrieving revision 1.97
diff -u -r1.96 -r1.97
--- index.html 2001/12/12 05:15:04 1.96
+++ index.html 2001/12/21 07:44:43 1.97
@@ -367,6 +367,14 @@
</li>
<li>
+ Win32 specific documentation:<br>
+ <a href="win32_binaries.html">Binaries</a> (<a
href="win32_binaries.pod">pod</a>)<br>
+ <a href="win32_compile.html">Compilation</a> (<a
href="win32_compile.pod">pod</a>)<br>
+ <a href="win32_multithread.html">Multithreading</a> (<a
href="win32_multithread.pod">pod</a>)<br>
+ <br><br>
+ </li>
+
+ <li>
<a href="http://www.refcards.com/";>mod_perl reference
card</a> by Andrew Ford.
<br><br>
1.1 modperl-site/win32_binaries.html
Index: win32_binaries.html
===================================================================
<HTML>
<HEAD>
<TITLE>win32_binaries - obtaining Apache mod_perl-1.xx binaries for Win32</TITLE>
</HEAD>
<BODY>
<A NAME="__index__"></A>
<!-- INDEX BEGIN -->
<UL>
<LI><A HREF="#name">NAME</A></LI>
<LI><A HREF="#description">DESCRIPTION</A></LI>
<LI><A HREF="#allinone packages">ALL-IN-ONE PACKAGES</A></LI>
<LI><A HREF="#ppm packages">PPM Packages</A></LI>
<LI><A HREF="#configuration">CONFIGURATION</A></LI>
<UL>
<LI><A HREF="#registry scripts">Registry scripts</A></LI>
<LI><A HREF="#hello world">Hello World</A></LI>
</UL>
<LI><A HREF="#apache modules">APACHE MODULES</A></LI>
<LI><A HREF="#see also">SEE ALSO</A></LI>
</UL>
<!-- INDEX END -->
<HR>
<P>
<H1><A NAME="name">NAME</A></H1>
<P>win32_binaries - obtaining Apache mod_perl-1.xx binaries for Win32</P>
<P>
<HR>
<H1><A NAME="description">DESCRIPTION</A></H1>
<P>This document discusses the two major types of binary packages
available for Win32 mod_perl - all-in-one Perl/Apache/mod_perl
binaries, and mod_perl ppm (Perl Package Manager) packages.</P>
<P>
<HR>
<H1><A NAME="allinone packages">ALL-IN-ONE PACKAGES</A></H1>
<P>There are at least two binary packages for Win32 that contain the
necessary Perl and Apache binaries:</P>
<PRE>
<A HREF="http://www.indigostar.com/";>http://www.indigostar.com/</A></PRE>
<PRE>
<A
HREF="ftp://theoryx5.uwinnipeg.ca/pub/other/perl-win32-bin-x.x.exe";>ftp://theoryx5.uwinnipeg.ca/pub/other/perl-win32-bin-x.x.exe</A></PRE>
<P>As well as including a number of non-core modules, both of these
packages contain mod_perl. See the documentation on the web sites and
that included with the packages for installation instructions. Both of
these also include an ActiveState-compatible <CODE>ppm</CODE> (Perl Package
Manager) utility for adding and upgrading modules.</P>
<P>
<HR>
<H1><A NAME="ppm packages">PPM Packages</A></H1>
<P>For users of ActivePerl, available from</P>
<PRE>
<A HREF="http://www.activestate.com/";>http://www.activestate.com/</A></PRE>
<P>there are also <CODE>PPM</CODE> mod_perl packages available. For this, if you
don't already have it, get and install the latest Win32 Apache binary
from</P>
<PRE>
<A HREF="http://httpd.apache.org/";>http://httpd.apache.org/</A></PRE>
<P>Both ActivePerl and Apache binaries are available as <CODE>MSI</CODE> files for
use by the Microsoft Installer - as discussed on the ActiveState site,
users of Windows 95 and 98 may need to obtain this. In installing
these packages, you may find it convenient when transcribing any
Unix-oriented documentation to choose installation directories that do
not have spaces in their names (eg, <EM>C:\Perl</EM> and <EM>C:\Apache</EM>).</P>
<P>After installing Perl and Apache, you can then install mod_perl via
the PPM utility. ActiveState does not maintain mod_perl in the ppm
repository, so you must get it from a different location other than
ActiveState's site. One way is simply as (broken over two lines for
readability)</P>
<PRE>
C:\> ppm install
<A
HREF="http://theoryx5.uwinnipeg.ca/ppmpackages/mod_perl.ppd";>http://theoryx5.uwinnipeg.ca/ppmpackages/mod_perl.ppd</A></PRE>
<P>Another way, which will be useful if you plan on installing additional
Apache modules, is to set the repository within the <CODE>ppm</CODE> shell
utility as (the <CODE>set repository ...</CODE> command has been broken over two
lines for readability):</P>
<PRE>
C:\> ppm
PPM> set repository theoryx5
<A
HREF="http://theoryx5.uwinnipeg.ca/cgi-bin/ppmserver?urn:/PPMServer";>http://theoryx5.uwinnipeg.ca/cgi-bin/ppmserver?urn:/PPMServer</A>
PPM> install mod_perl
PPM> set save
PPM> quit
C:\></PRE>
<P>The <CODE>set save</CODE> command saves the <CODE>theoryx5</CODE> repository to
your PPM
configuration file, so that future PPM sessions will search this
repository, as well as ActiveState's, for requested packages.</P>
<P>The mod_perl PPM package also includes the necessary Apache DLL
<CODE>mod_perl.so</CODE>; a post-installation script should be run which will
offer to copy this file to your Apache modules directory (eg,
<EM>C:\Apache\modules</EM>).</P>
<P>Note that the mod_perl package available from this site will always
use the latest mod_perl sources compiled against the latest official
Apache release; depending on changes made in Apache, you may or may
not be able to use an earlier Apache binary. However, in the Apache
Win32 world it is particularly a good idea to use the latest version,
for bug and security fixes.</P>
<P>
<HR>
<H1><A NAME="configuration">CONFIGURATION</A></H1>
<P>Add this line to <EM>C:\Apache\conf\httpd.conf</EM>:</P>
<PRE>
LoadModule perl_module modules/mod_perl.so</PRE>
<P>Be sure that the path to your Perl binary (eg, <EM>C:\Perl\bin</EM>) is in
your <CODE>PATH</CODE> environment variable.</P>
<P>
<H2><A NAME="registry scripts">Registry scripts</A></H2>
<P>Using <CODE>Apache::Registry</CODE> to speed up cgi scripts may be done as
follows. Create a directory, for example, <EM>C:\Apache\mod_perl</EM>, which
will hold your scripts. Insert then in <EM>C:\Apache\conf\httpd.conf</EM>
the following directives:</P>
<PRE>
Alias /mod_perl/ "/Apache/mod_perl/"
<Location /mod_perl>
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
PerlSendHeader On
</Location></PRE>
<P>whereby the script would be called as</P>
<PRE>
<A
HREF="http://localhost/mod_perl/name_of_script";>http://localhost/mod_perl/name_of_script</A></PRE>
<P>
<H2><A NAME="hello world">Hello World</A></H2>
<P>As you will discover, there is much to mod_perl beyond simple speed-up
of cgi scripts. Here is a simple <EM>Hello, World</EM> example that
illustrates the use of mod_perl as a content handler. Create a file
<EM>Hello.pm</EM> as follows:</P>
<PRE>
package Apache::Hello;
use strict;
use Apache::Constants qw(OK);</PRE>
<PRE>
sub handler {
my $r = shift;
$r->send_http_header;
$r->print("<html><body>Hello
World!</body></html>\n");
return OK;
}</PRE>
<PRE>
1;</PRE>
<P>and save it in, for example, the <EM>C:\Perl\site\lib\Apache\</EM>
directory. Next put the following directives in
<EM>C:\Apache\conf\httpd.conf</EM>:</P>
<PRE>
PerlModule Apache::Hello
<Location /hello>
SetHandler perl-script
PerlHandler Apache::Hello
</Location></PRE>
<P>With this, calls to</P>
<PRE>
<A HREF="http://localhost/hello";>http://localhost/hello</A></PRE>
<P>will use <CODE>Apache::Hello</CODE> to deliver the content.</P>
<P>
<HR>
<H1><A NAME="apache modules">APACHE MODULES</A></H1>
<P>The <CODE>theorxy5</CODE> repository containing the mod_perl ppm package also
contains a number of other Apache modules, such as <CODE>Apache::ASP</CODE>,
<CODE>HTML::Embperl</CODE>, and <CODE>HTML::Mason</CODE>. However, there may be ones
you
find that are not available through a repository; in such cases, you
might try sending a message to the maintainer of the repository asking
if a particular package could be included, or you could use the
<CODE>CPAN.pm</CODE> module to fetch, build, and install the module - see
<CODE>perldoc CPAN</CODE> for details.</P>
<P>
<HR>
<H1><A NAME="see also">SEE ALSO</A></H1>
<P><EM>mod_perl</EM>, <EM>Apache</EM>, <A
HREF="http://perl.apache.org/,";>http://perl.apache.org/,</A> especially the guide,
<A HREF="http://take23.org/,";>http://take23.org/,</A> <A
HREF="http://httpd.apache.org/,";>http://httpd.apache.org/,</A> and
<A HREF="http://www.activestate.com/.";>http://www.activestate.com/.</A></P>
</BODY>
</HTML>
1.1 modperl-site/win32_binaries.pod
Index: win32_binaries.pod
===================================================================
=head1 NAME
win32_binaries - obtaining Apache mod_perl-1.xx binaries for Win32
=head1 DESCRIPTION
This document discusses the two major types of binary packages
available for Win32 mod_perl - all-in-one Perl/Apache/mod_perl
binaries, and mod_perl ppm (Perl Package Manager) packages.
=head1 ALL-IN-ONE PACKAGES
There are at least two binary packages for Win32 that contain the
necessary Perl and Apache binaries:
http://www.indigostar.com/
ftp://theoryx5.uwinnipeg.ca/pub/other/perl-win32-bin-x.x.exe
As well as including a number of non-core modules, both of these
packages contain mod_perl. See the documentation on the web sites and
that included with the packages for installation instructions. Both of
these also include an ActiveState-compatible C<ppm> (Perl Package
Manager) utility for adding and upgrading modules.
=head1 PPM Packages
For users of ActivePerl, available from
http://www.activestate.com/
there are also C<PPM> mod_perl packages available. For this, if you
don't already have it, get and install the latest Win32 Apache binary
from
http://httpd.apache.org/
Both ActivePerl and Apache binaries are available as C<MSI> files for
use by the Microsoft Installer - as discussed on the ActiveState site,
users of Windows 95 and 98 may need to obtain this. In installing
these packages, you may find it convenient when transcribing any
Unix-oriented documentation to choose installation directories that do
not have spaces in their names (eg, F<C:\Perl> and F<C:\Apache>).
After installing Perl and Apache, you can then install mod_perl via
the PPM utility. ActiveState does not maintain mod_perl in the ppm
repository, so you must get it from a different location other than
ActiveState's site. One way is simply as (broken over two lines for
readability)
C:\> ppm install
http://theoryx5.uwinnipeg.ca/ppmpackages/mod_perl.ppd
Another way, which will be useful if you plan on installing additional
Apache modules, is to set the repository within the C<ppm> shell
utility as (the C<set repository ...> command has been broken over two
lines for readability):
C:\> ppm
PPM> set repository theoryx5
http://theoryx5.uwinnipeg.ca/cgi-bin/ppmserver?urn:/PPMServer
PPM> install mod_perl
PPM> set save
PPM> quit
C:\>
The C<set save> command saves the C<theoryx5> repository to your PPM
configuration file, so that future PPM sessions will search this
repository, as well as ActiveState's, for requested packages.
The mod_perl PPM package also includes the necessary Apache DLL
C<mod_perl.so>; a post-installation script should be run which will
offer to copy this file to your Apache modules directory (eg,
F<C:\Apache\modules>).
Note that the mod_perl package available from this site will always
use the latest mod_perl sources compiled against the latest official
Apache release; depending on changes made in Apache, you may or may
not be able to use an earlier Apache binary. However, in the Apache
Win32 world it is particularly a good idea to use the latest version,
for bug and security fixes.
=head1 CONFIGURATION
Add this line to F<C:\Apache\conf\httpd.conf>:
LoadModule perl_module modules/mod_perl.so
Be sure that the path to your Perl binary (eg, F<C:\Perl\bin>) is in
your C<PATH> environment variable.
=head2 Registry scripts
Using C<Apache::Registry> to speed up cgi scripts may be done as
follows. Create a directory, for example, F<C:\Apache\mod_perl>, which
will hold your scripts. Insert then in F<C:\Apache\conf\httpd.conf>
the following directives:
Alias /mod_perl/ "/Apache/mod_perl/"
<Location /mod_perl>
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
PerlSendHeader On
</Location>
whereby the script would be called as
http://localhost/mod_perl/name_of_script
=head2 Hello World
As you will discover, there is much to mod_perl beyond simple speed-up
of cgi scripts. Here is a simple I<Hello, World> example that
illustrates the use of mod_perl as a content handler. Create a file
F<Hello.pm> as follows:
package Apache::Hello;
use strict;
use Apache::Constants qw(OK);
sub handler {
my $r = shift;
$r->send_http_header;
$r->print("<html><body>Hello World!</body></html>\n");
return OK;
}
1;
and save it in, for example, the F<C:\Perl\site\lib\Apache\>
directory. Next put the following directives in
F<C:\Apache\conf\httpd.conf>:
PerlModule Apache::Hello
<Location /hello>
SetHandler perl-script
PerlHandler Apache::Hello
</Location>
With this, calls to
http://localhost/hello
will use C<Apache::Hello> to deliver the content.
=head1 APACHE MODULES
The C<theorxy5> repository containing the mod_perl ppm package also
contains a number of other Apache modules, such as C<Apache::ASP>,
C<HTML::Embperl>, and C<HTML::Mason>. However, there may be ones you
find that are not available through a repository; in such cases, you
might try sending a message to the maintainer of the repository asking
if a particular package could be included, or you could use the
C<CPAN.pm> module to fetch, build, and install the module - see
C<perldoc CPAN> for details.
=head1 SEE ALSO
L<mod_perl>, L<Apache>, http://perl.apache.org/, especially the guide,
http://take23.org/, http://httpd.apache.org/, and
http://www.activestate.com/.
=cut
1.1 modperl-site/win32_compile.html
Index: win32_compile.html
===================================================================
<HTML>
<HEAD>
<TITLE>win32_compile - Apache mod_perl-1.xx installation instructions for
Win32</TITLE>
</HEAD>
<BODY>
<A NAME="__index__"></A>
<!-- INDEX BEGIN -->
<UL>
<LI><A HREF="#name">NAME</A></LI>
<LI><A HREF="#description">DESCRIPTION</A></LI>
<LI><A HREF="#prerequisites">PREREQUISITES</A></LI>
<LI><A HREF="#building">BUILDING</A></LI>
<UL>
<LI><A HREF="#building with ms developer studio">Building with MS
Developer Studio</A></LI>
<LI><A HREF="#building with arguments to perl makefile.pl">Building
with arguments to <CODE>perl Makefile.PL</CODE></A></LI>
</UL>
<LI><A HREF="#configuration">CONFIGURATION</A></LI>
<LI><A HREF="#see also">SEE ALSO</A></LI>
</UL>
<!-- INDEX END -->
<HR>
<P>
<H1><A NAME="name">NAME</A></H1>
<P>win32_compile - Apache mod_perl-1.xx installation instructions for Win32</P>
<P>
<HR>
<H1><A NAME="description">DESCRIPTION</A></H1>
<P>This document discusses how to build, test, configure and
install mod_perl under Win32.</P>
<P>
<HR>
<H1><A NAME="prerequisites">PREREQUISITES</A></H1>
<P>patience - mod_perl is considered alpha under Win32.</P>
<P>MSVC++ 5.0+, Apache version 1.3-dev or higher and Perl 5.004_02 or higher.</P>
<P>As of version 1.24_01, mod_perl will build on Win32 ActivePerls
based on Perl-5.6.x (builds 6xx). For binary compatibility you
should use the same compiler in building mod_perl that was used
to compile your Perl binary; for ActivePerl, this means using VC++ 6.</P>
<P>
<HR>
<H1><A NAME="building">BUILDING</A></H1>
<P>Obtain the mod_perl sources from CPAN:</P>
<PRE>
<A
HREF="http://www.cpan.org/authors/id/D/DO/DOUGM/mod_perl-1.xx.tar.gz";>http://www.cpan.org/authors/id/D/DO/DOUGM/mod_perl-1.xx.tar.gz</A></PRE>
<P>When unpacked, using Winzip or similar tools, a subdirectory
<EM>mod_perl-1.xx</EM> will be created.</P>
<P>There are two ways to build mod_perl - with MS Developer Studio,
and through command-line arguments to 'perl Makefile.PL'. In both
cases Apache should previously have been built and installed - if
you are using a binary build of Apache, make sure that you obtain
a binary build that includes the Apache libraries and header files.</P>
<P>
<H2><A NAME="building with ms developer studio">Building with MS Developer
Studio</A></H2>
<DL>
<DT><STRONG><A NAME="item_Setup_the_Perl_side">Setup the Perl side</A></STRONG><BR>
<DD>
Run, from a DOS window in the top-level directory of the
mod_perl sources,
<PRE>
perl Makefile.PL
nmake</PRE>
<P>This will set up the Perl side of mod_perl for the library build.</P>
<P></P>
<DT><STRONG><A NAME="item_Build_mod_perl%2Eso">Build mod_perl.so</A></STRONG><BR>
<DD>
Using MS developer studio,
<PRE>
select "File -> Open Workspace ...",
select "Files of type [Projects (*.dsp)]"
open mod_perl-x.xx/src/modules/win32/mod_perl.dsp</PRE>
<P></P>
<DT><STRONG><A NAME="item_Settings">Settings</A></STRONG><BR>
<DD>
<PRE>
select "Tools -> Options -> [Directories]"
select "Show directories for: [Include files]", and add
C:\Apache\include
. (should expand to C:\...\mod_perl-x.xx\src\modules\perl)
C:\Perl\lib\Core</PRE>
<PRE>
select "Project -> Add to Project -> Files", adding:
perl.lib (or perl56.lib) (e.g. C:\perl\lib\Core\perl.lib)
ApacheCore.lib (e.g. C:\Apache\ApacheCore.lib)</PRE>
<PRE>
select "Build -> Set Active Configuration -> [mod_perl - Win32
Release]"</PRE>
<PRE>
select "Build -> Build mod_perl.so"</PRE>
<P>You may see some harmless warnings, which can be reduced (along with
the size of the DLL), by setting:</P>
<PRE>
"Project -> Settings -> [C/C++] -> Category: [Code Generation] ->
Use runtime library: [Multithreaded DLL]</PRE>
<DT><STRONG><A NAME="item_Testing">Testing</A></STRONG><BR>
<DD>
Once mod_perl.so is built you may test mod_perl with:
<PRE>
nmake test</PRE>
<P>after which, assuming the tests are OK,</P>
<PRE>
nmake install</PRE>
<P>will install the Perl side of mod_perl. The mod_perl.so file
built under <EM>mod_perl-1.xx/src/modules/win32/Release</EM> should
be copied to your Apache modules directory (eg, <EM>C:\Apache\modules</EM>).</P>
<P></P></DL>
<P>
<H2><A NAME="building with arguments to perl makefile.pl">Building with arguments to
<CODE>perl Makefile.PL</CODE></A></H2>
<P>Generating the Makefile as, for example,</P>
<PRE>
perl Makefile.PL APACHE_SRC=\Apache INSTALL_DLL=\Apache\modules</PRE>
<P>will build mod_perl (including mod_perl.so) entirely from
the command line. The arguments accepted include</P>
<DL>
<DT><STRONG><A NAME="item_APACHE_SRC">APACHE_SRC</A></STRONG><BR>
<DD>
This can be one of two values: either the path to the Apache build
directory (eg, <EM>..\apache_1.3.xx</EM>), or to the installed Apache location
(eg, <EM>\Apache</EM>). This is used to set the locations of ApacheCore.lib
and the Apache header files.
<P></P>
<DT><STRONG><A NAME="item_INSTALL_DLL">INSTALL_DLL</A></STRONG><BR>
<DD>
This gives the location of where to install mod_perl.so
(eg, <EM>\Apache\modules</EM>). No default is assumed - if this argument
is not given, mod_perl.so must be copied manually.
<P></P>
<DT><STRONG><A NAME="item_DEBUG">DEBUG</A></STRONG><BR>
<DD>
If true (DEBUG=1), a Debug version will be built (this assumes
that a Debug Apache has been built). If false, or not given,
a Release version will be built.
<P></P>
<DT><STRONG><A NAME="item_EAPI">EAPI</A></STRONG><BR>
<DD>
If true (EAPI=1), EAPI (Extended API) will be defined when
compiling. This is useful when building mod_perl against mod_ssl
patched Apache sources. If false, or not given, EAPI will
not be defined.
<P></P></DL>
<P>After this, running</P>
<PRE>
nmake
nmake test
nmake install</PRE>
<P>will complete the installation.</P>
<P>This latter method of building mod_perl will also install the
Apache and mod_perl header files, which can then be accessed
through the Apache::src module.</P>
<P>
<HR>
<H1><A NAME="configuration">CONFIGURATION</A></H1>
<P>Add this line to <EM>C:\Apache\conf\httpd.conf</EM>:</P>
<PRE>
LoadModule perl_module modules/mod_perl.so</PRE>
<P>Be sure that the path to your Perl binary (eg, <EM>C:\Perl\bin</EM>)
is in your <CODE>PATH</CODE> environment variable.</P>
<P>
<HR>
<H1><A NAME="see also">SEE ALSO</A></H1>
<P><EM>mod_perl</EM>, <EM>Apache</EM>, <A
HREF="http://perl.apache.org/,";>http://perl.apache.org/,</A> especially
the guide, and <A HREF="http://take23.org/.";>http://take23.org/.</A></P>
</BODY>
</HTML>
1.1 modperl-site/win32_compile.pod
Index: win32_compile.pod
===================================================================
=head1 NAME
win32_compile - Apache mod_perl-1.xx installation instructions for Win32
=head1 DESCRIPTION
This document discusses how to build, test, configure and
install mod_perl under Win32.
=head1 PREREQUISITES
=over 3
patience - mod_perl is considered alpha under Win32.
MSVC++ 5.0+, Apache version 1.3-dev or higher and Perl 5.004_02 or higher.
As of version 1.24_01, mod_perl will build on Win32 ActivePerls
based on Perl-5.6.x (builds 6xx). For binary compatibility you
should use the same compiler in building mod_perl that was used
to compile your Perl binary; for ActivePerl, this means using VC++ 6.
=back
=head1 BUILDING
Obtain the mod_perl sources from CPAN:
http://www.cpan.org/authors/id/D/DO/DOUGM/mod_perl-1.xx.tar.gz
When unpacked, using Winzip or similar tools, a subdirectory
F<mod_perl-1.xx> will be created.
There are two ways to build mod_perl - with MS Developer Studio,
and through command-line arguments to 'perl Makefile.PL'. In both
cases Apache should previously have been built and installed - if
you are using a binary build of Apache, make sure that you obtain
a binary build that includes the Apache libraries and header files.
=head2 Building with MS Developer Studio
=over 3
=item Setup the Perl side
Run, from a DOS window in the top-level directory of the
mod_perl sources,
perl Makefile.PL
nmake
This will set up the Perl side of mod_perl for the library build.
=item Build mod_perl.so
Using MS developer studio,
select "File -> Open Workspace ...",
select "Files of type [Projects (*.dsp)]"
open mod_perl-x.xx/src/modules/win32/mod_perl.dsp
=item Settings
select "Tools -> Options -> [Directories]"
select "Show directories for: [Include files]", and add
C:\Apache\include
. (should expand to C:\...\mod_perl-x.xx\src\modules\perl)
C:\Perl\lib\Core
select "Project -> Add to Project -> Files", adding:
perl.lib (or perl56.lib) (e.g. C:\perl\lib\Core\perl.lib)
ApacheCore.lib (e.g. C:\Apache\ApacheCore.lib)
select "Build -> Set Active Configuration -> [mod_perl - Win32 Release]"
select "Build -> Build mod_perl.so"
You may see some harmless warnings, which can be reduced (along with
the size of the DLL), by setting:
"Project -> Settings -> [C/C++] -> Category: [Code Generation] ->
Use runtime library: [Multithreaded DLL]
=item Testing
Once mod_perl.so is built you may test mod_perl with:
nmake test
after which, assuming the tests are OK,
nmake install
will install the Perl side of mod_perl. The mod_perl.so file
built under F<mod_perl-1.xx/src/modules/win32/Release> should
be copied to your Apache modules directory (eg, F<C:\Apache\modules>).
=back
=head2 Building with arguments to C<perl Makefile.PL>
Generating the Makefile as, for example,
perl Makefile.PL APACHE_SRC=\Apache INSTALL_DLL=\Apache\modules
will build mod_perl (including mod_perl.so) entirely from
the command line. The arguments accepted include
=over 3
=item APACHE_SRC
This can be one of two values: either the path to the Apache build
directory (eg, F<..\apache_1.3.xx>), or to the installed Apache location
(eg, F<\Apache>). This is used to set the locations of ApacheCore.lib
and the Apache header files.
=item INSTALL_DLL
This gives the location of where to install mod_perl.so
(eg, F<\Apache\modules>). No default is assumed - if this argument
is not given, mod_perl.so must be copied manually.
=item DEBUG
If true (DEBUG=1), a Debug version will be built (this assumes
that a Debug Apache has been built). If false, or not given,
a Release version will be built.
=item EAPI
If true (EAPI=1), EAPI (Extended API) will be defined when
compiling. This is useful when building mod_perl against mod_ssl
patched Apache sources. If false, or not given, EAPI will
not be defined.
=back
After this, running
nmake
nmake test
nmake install
will complete the installation.
This latter method of building mod_perl will also install the
Apache and mod_perl header files, which can then be accessed
through the Apache::src module.
=head1 CONFIGURATION
Add this line to F<C:\Apache\conf\httpd.conf>:
LoadModule perl_module modules/mod_perl.so
Be sure that the path to your Perl binary (eg, F<C:\Perl\bin>)
is in your C<PATH> environment variable.
=head1 SEE ALSO
L<mod_perl>, L<Apache>, http://perl.apache.org/, especially
the guide, and http://take23.org/.
=cut
1.1 modperl-site/win32_multithread.html
Index: win32_multithread.html
===================================================================
<HTML>
<HEAD>
<TITLE>win32_multithread - discussion of multithreading on Win32
mod_perl-1.xx</TITLE>
</HEAD>
<BODY>
<A NAME="__index__"></A>
<!-- INDEX BEGIN -->
<UL>
<LI><A HREF="#name">NAME</A></LI>
<LI><A HREF="#description">DESCRIPTION</A></LI>
<LI><A HREF="#the problem">The problem</A></LI>
<LI><A HREF="#does it really matter">Does it really matter?</A></LI>
<LI><A HREF="#workarounds">Workarounds</A></LI>
<LI><A HREF="#see also">SEE ALSO</A></LI>
</UL>
<!-- INDEX END -->
<HR>
<P>
<H1><A NAME="name">NAME</A></H1>
<P>win32_multithread - discussion of multithreading on Win32 mod_perl-1.xx</P>
<P>
<HR>
<H1><A NAME="description">DESCRIPTION</A></H1>
<P>This document discusses the multithreading limitations of
mod_perl-1.xx on Win32.</P>
<P>
<HR>
<H1><A NAME="the problem">The problem</A></H1>
<P>On Win32, mod_perl is effectively single threaded. What this
means is that a single instance of the interpreter is created,
and this is then protected by a server-wide lock that prevents
more than one thread from using the interpreter at any one time.
The fact that this will prevent parallel processing of requests,
including static requests, can have serious implications for
production servers that often must handle concurrent or
long-running requests.</P>
<P>This situation will change with Apache/mod_perl 2.0, which is
based on a multi-process/multi-thread approach using a native
Win32 threads implementation. See
<A
HREF="http://perl.apache.org/~dougm/modperl_2.0.html";>http://perl.apache.org/~dougm/modperl_2.0.html</A>
for details.</P>
<P>At the time of writing, Apache-2.0 is in a beta stage of
development. mod_perl-2.0 is being actively developed, including the
Win32 port; if you would like a preview and/or would like to
contribute to the development process, see the documents on obtaining
mod_perl-2.0 by cvs, which can be obtained from mod_perl's home page
at <A HREF="http://perl.apache.org/.";>http://perl.apache.org/.</A></P>
<P>
<HR>
<H1><A NAME="does it really matter">Does it really matter?</A></H1>
<P>How serious is this? For some people and application classes it may be a
non-problem, assuming the static material issue is handled differently.</P>
<P>Low traffic and single user development sites will likely be
unaffected (though the lattest are likely to experience some surprises
when moving to an environment where requests are no longer serialized
and concurrency kicks in).</P>
<P>If your application is CPU bound, and all requests take roughly the
same time to complete, then having more processing threads than
processors (CPUs) will actually slow things down, because of the
context switching overhead. Note that, even in this case, the current
state of mod_perl will bar owners of multiprocessor Win32 machines
from gaining any load balancing advantage from their superior hardware.</P>
<P>On the other hand, applications dealing with a large service times
spread - say ranging from fractions of a second to a minute and above
- stand to lose a great deal of responsiveness from being single
threaded. The reason is that short requests that happen to be queueued
after long ones will be delayed for the entire duration of the ``jobs''
that precede them in the queue; with multitasking they would get a chance
to complete much earlier.</P>
<P>
<HR>
<H1><A NAME="workarounds">Workarounds</A></H1>
<P>If you need multithreading on Win32, either because your application
has long running requests, or because you can afford multiprocessor
hardware, and assuming you cannot switch operating systems, you may
want to consider a few workarounds and/or alternatives - which do not
require waiting for 2.0.</P>
<P>You may be able to make Win32 multithreading a non-issue by tuning or
rearranging your application and your architecture (useful tips on
both counts can be found elsewhere in this document). You may be able
to significantly reduce your worst-case timing problems or you may
find that you can move the webserver to a more mod_perl friendly
operating system by using a multi-tier scheme.</P>
<P>If your application needs the full power of the Apache modules (often
the case for people running outside Apache::Registry) you may want to
consider a multi-server load balancing setup which uses mod_rewrite
(or a similar URL partitioning scheme) to spread requests to several web
servers, listening on different ports.</P>
<P>The mod_proxy dual server setup, discussed in the ``Strategy'' section,
is also a possibility, although people who have tried it have reported
problems with Win32 mod_proxy.</P>
<P>If you code to Apache::Registry (writing CGI compliant code) and can
characterize the time demanded by a request from its URL, you can use
a rewrite-based load balancing with a single server, by sending short
requests to mod_perl while routing longer ones to the pure CGI
environment - on the basis that startup, compilation and init times
will matter less in this case.</P>
<P>If none of the above works for you, then you will have to turn to some
non mod_perl alternatives: this, however, implies giving up on most of
the flexibility of the Apache modules.</P>
<P>For CGI compliant scripts, two possible (portable) alternatives which
are supported in an Apache/perl environment are straight CGI and
FastCGI. In theory a CGI application that runs under mod_perl should
have very few or no problems to run under straight CGI (though its
performance may be unacceptable). A FastCGI port should also be
relatively painless. However, as always, your mileage may vary.</P>
<P>If you do not mind replacing Apache with IIS/PWS, you may want
to experiment with ActiveState's value added PerlEx extension, which
speeds up CGI scripts much in a way similar to what FastCGI
does. PerlEx is transparently supported by CGI.pm, so users of this
package should be more or less covered. (A IIS-FastCGI accelerator is,
regrettably, no longer available.)</P>
<P>
<HR>
<H1><A NAME="see also">SEE ALSO</A></H1>
<P><A HREF="http://perl.apache.org";>http://perl.apache.org</A> and <A
HREF="http://httpd.apache.org,";>http://httpd.apache.org,</A> especially the
discussion of Apache-2 and modperl-2.</P>
</BODY>
</HTML>
1.1 modperl-site/win32_multithread.pod
Index: win32_multithread.pod
===================================================================
=head1 NAME
win32_multithread - discussion of multithreading on Win32 mod_perl-1.xx
=head1 DESCRIPTION
This document discusses the multithreading limitations of
mod_perl-1.xx on Win32.
=head1 The problem
On Win32, mod_perl is effectively single threaded. What this
means is that a single instance of the interpreter is created,
and this is then protected by a server-wide lock that prevents
more than one thread from using the interpreter at any one time.
The fact that this will prevent parallel processing of requests,
including static requests, can have serious implications for
production servers that often must handle concurrent or
long-running requests.
This situation will change with Apache/mod_perl 2.0, which is
based on a multi-process/multi-thread approach using a native
Win32 threads implementation. See
http://perl.apache.org/~dougm/modperl_2.0.html for details.
At the time of writing, Apache-2.0 is in a beta stage of
development. mod_perl-2.0 is being actively developed, including the
Win32 port; if you would like a preview and/or would like to
contribute to the development process, see the documents on obtaining
mod_perl-2.0 by cvs, which can be obtained from mod_perl's home page
at http://perl.apache.org/.
=head1 Does it really matter?
How serious is this? For some people and application classes it may be a
non-problem, assuming the static material issue is handled differently.
Low traffic and single user development sites will likely be
unaffected (though the lattest are likely to experience some surprises
when moving to an environment where requests are no longer serialized
and concurrency kicks in).
If your application is CPU bound, and all requests take roughly the
same time to complete, then having more processing threads than
processors (CPUs) will actually slow things down, because of the
context switching overhead. Note that, even in this case, the current
state of mod_perl will bar owners of multiprocessor Win32 machines
from gaining any load balancing advantage from their superior hardware.
On the other hand, applications dealing with a large service times
spread - say ranging from fractions of a second to a minute and above
- stand to lose a great deal of responsiveness from being single
threaded. The reason is that short requests that happen to be queueued
after long ones will be delayed for the entire duration of the "jobs"
that precede them in the queue; with multitasking they would get a chance
to complete much earlier.
=head1 Workarounds
If you need multithreading on Win32, either because your application
has long running requests, or because you can afford multiprocessor
hardware, and assuming you cannot switch operating systems, you may
want to consider a few workarounds and/or alternatives - which do not
require waiting for 2.0.
You may be able to make Win32 multithreading a non-issue by tuning or
rearranging your application and your architecture (useful tips on
both counts can be found elsewhere in this document). You may be able
to significantly reduce your worst-case timing problems or you may
find that you can move the webserver to a more mod_perl friendly
operating system by using a multi-tier scheme.
If your application needs the full power of the Apache modules (often
the case for people running outside Apache::Registry) you may want to
consider a multi-server load balancing setup which uses mod_rewrite
(or a similar URL partitioning scheme) to spread requests to several web
servers, listening on different ports.
The mod_proxy dual server setup, discussed in the "Strategy" section,
is also a possibility, although people who have tried it have reported
problems with Win32 mod_proxy.
If you code to Apache::Registry (writing CGI compliant code) and can
characterize the time demanded by a request from its URL, you can use
a rewrite-based load balancing with a single server, by sending short
requests to mod_perl while routing longer ones to the pure CGI
environment - on the basis that startup, compilation and init times
will matter less in this case.
If none of the above works for you, then you will have to turn to some
non mod_perl alternatives: this, however, implies giving up on most of
the flexibility of the Apache modules.
For CGI compliant scripts, two possible (portable) alternatives which
are supported in an Apache/perl environment are straight CGI and
FastCGI. In theory a CGI application that runs under mod_perl should
have very few or no problems to run under straight CGI (though its
performance may be unacceptable). A FastCGI port should also be
relatively painless. However, as always, your mileage may vary.
If you do not mind replacing Apache with IIS/PWS, you may want
to experiment with ActiveState's value added PerlEx extension, which
speeds up CGI scripts much in a way similar to what FastCGI
does. PerlEx is transparently supported by CGI.pm, so users of this
package should be more or less covered. (A IIS-FastCGI accelerator is,
regrettably, no longer available.)
=head1 SEE ALSO
http://perl.apache.org and http://httpd.apache.org, especially the
discussion of Apache-2 and modperl-2.
=cut
