cvs commit: modperl/faq mod_perl_faq.pod mod_perl_cgi.pod

[fd...@hyperreal.org]

fdc         98/05/28 14:55:39

  Modified:    faq      mod_perl_faq.pod mod_perl_cgi.pod
  Log:
  FAQ updated to reflect new mailing list location.
  New mailing list archives added.
  
  Description of exit() and Apache::exit() brought up to date.
  
  Mention Apache::PerlRun in the CGI pod.
  
  Revision  Changes    Path
  1.7       +7 -3      modperl/faq/mod_perl_faq.pod
  
  Index: mod_perl_faq.pod
  ===================================================================
  RCS file: /export/home/cvs/modperl/faq/mod_perl_faq.pod,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- mod_perl_faq.pod	1998/03/19 23:08:37	1.6
  +++ mod_perl_faq.pod	1998/05/28 21:55:33	1.7
  @@ -1,6 +1,6 @@
   =head1 NAME
   
  -Mod_perl_faq - frequently asked questions about mod_perl ($Date: 1998/03/19 23:08:37 $)
  +Mod_perl_faq - frequently asked questions about mod_perl ($Date: 1998/05/28 21:55:33 $)
   
   =head1 DESCRIPTION
   
  @@ -375,10 +375,14 @@
   =head2 Where can I get help that I did not find in here?
   
   There is a mailing-list dedicated to mod_perl.  It is archived at
  -http://outside.organic.com/mail-archives/modperl/
  +http://outside.organic.com/mail-archives/modperl/ and at
  +http://forum.swarthmore.edu/epigone/modperl (which has a search
  +engine) and also at
  +http://www.progressive-comp.com/Lists/?l=apache-modperl&r=1#apache-modperl
  +(threaded and indexed).
   
   You can subscribe to the list by sending a mail with the line C<subscribe
  -modperl> to C<li...@listproc.itribe.net>.
  +modperl> to C<ma...@apache.org>.
   
   The mod_perl homepage http://perl.apache.org/ has links to other
   mod_perl resources.
  
  
  
  1.7       +22 -8     modperl/faq/mod_perl_cgi.pod
  
  Index: mod_perl_cgi.pod
  ===================================================================
  RCS file: /export/home/cvs/modperl/faq/mod_perl_cgi.pod,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- mod_perl_cgi.pod	1998/03/19 23:08:36	1.6
  +++ mod_perl_cgi.pod	1998/05/28 21:55:33	1.7
  @@ -1,6 +1,6 @@
   =head1 NAME
   
  -Mod_perl_cgi - running CGI scripts under mod_perl ($Date: 1998/03/19 23:08:36 $)
  +Mod_perl_cgi - running CGI scripts under mod_perl ($Date: 1998/05/28 21:55:33 $)
   
   =head1 DESCRIPTION
   
  @@ -66,11 +66,12 @@
   
   =head2 The server terminates after processing the first request
   
  -Your script is calling the perl C<exit()> function.  That is not a problem
  -in a conventional CGI script, provided that query processing is complete.
  -But you almost certainly don't want to exit in a mod_perl script.  It
  -kills the server process that handled the request, meaning that the
  -advantage of using mod_perl to avoid startup overhead is lost.
  +Your script is calling the CORE perl C<exit()> function.  That is not
  +a problem in a conventional CGI script, provided that query processing
  +is complete.  But you almost certainly don't want to exit in a
  +mod_perl script.  It kills the server process that handled the
  +request, meaning that the advantage of using mod_perl to avoid startup
  +overhead is lost.
   
   The best way to avoid calling C<exit()> is to restructure the script so
   that all execution paths return to a common point at the end of the
  @@ -78,8 +79,13 @@
   placing a label after the last executable statement and replacing calls to
   C<exit()> with C<goto label;>
   
  -There may be exceptional circumstances in which an exit is required in a
  -mod_perl script, in which case C<Apache-E<gt>exit()> should be used.
  +See also what mod_perl_traps says about C<Apache::exit()> and the way
  +that Apache::Registry causes it to terminate the script but not the
  +httpd child.
  +
  +There may be exceptional circumstances in which you explicitly want to
  +terminate the httpd child at the end of the current request.  In this
  +case C<Apache-E<gt>exit(-2)> should be used.
   
   =head2 Variables retain their value from one request to the next
   
  @@ -162,6 +168,14 @@
   happen if you have C<use CGI> in a script and pull the script in with
   a C<PerlRequire> directive in httpd.conf.  Replacing C<use CGI> with
   C<require CGI> will fix it.
  +
  +=head2 Do I have to rewrite my legacy code for mod_perl?
  +
  +If you have CGI code that seems to be fundamentally at odds with
  +mod_perl's "compile once, run many" environment, you may be find that
  +it will work if run under the module C<Apache::PerlRun>.  See the
  +documentation of that module, which is included with recent versions
  +of mod_perl.
   
   =head1 How can my script continue running after sending the response?