perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Foertsch <>
Subject Re: Question about Apache2::ServerUtil and PerlCleanupHandler
Date Fri, 05 Dec 2008 14:50:35 GMT
On Fri 05 Dec 2008, Kostas Chatzikokolakis wrote:
> I'd like to ask what is the intended behaviour of
>  Apache2::ServerUtil->server->push_handlers(PerlCleanupHandler =>
> ...) compared to
>  Apache2::RequestUtil->request->push_handlers(PerlCleanupHandler =>
> ...)
> On my Ubuntu 8.10 (mod_perl 2.0.4, apache 2.2.9) cleanup handlers
> installed on $s seem to be called after *every* request but handlers
> installed on $r are called only *once* after the *current* request.
> On a RedHat ES 5 (mod_perl 2.0.2, apache 2.2.3) cleanup handlers on
> $s look like they are never called.
> I found and old list message suggesting that cleanup handlers on $s
> are called when the server is terminated, but this doesn't seem to be
> the case (and looks strange since we have PerlChildExitHandler for
> that). In the documentation of handlers, there is no mention of where
> each handler must be installed and whether it makes a difference.
> NOTE: on my Ubuntu, a cleanup handler installed on $s is called only
> if there are also other types of handlers on $s. In the Changelog of
> the *threading branch* I found the following message
>   Now correctly invokes PerlCleanupHandlers, even if they are the
> only handler type configured for that request [Torsten Foertsch]
> this comes from r594609 but it was not merged for 2.0.4. This maybe
> happens also for $r handlers, but on my setup $r has always at least
> a PerlResponseHandler so I'm not sure.

Apache request configuration is performed in 2 steps. The first occurs 
at startup the second at runtime. At startup one configuration object 
per virtual server is created. At runtime a request inherits from that 
config but other request specific configuration sources (Location 
blocks, .htaccess files etc) are merged.

$s->push_handlers as well as $s->add_config modify the server 
configuration object while $r->... modify the runtime request 
configuration. The server methods are intended to be used only at 
startup time (up to PerlPostConfig, perhaps PerlChildInit works too). 
Later the server configuration must be read-only or you risk segfaults 
at least on a threaded MPM.

The PerlCleanup phase is an artificial thing that is implemented as a 
pool cleanup function on the request pool. But it needs to be 
registered on the request pool to be run. If there is no Perl handler 
in the request cycle the pool cleanup is never installed. The patch you 
mentioned fixes that but it depends on an other interpreter management 
(the heart of the threading branch). Hence, if you need that use the 
threading branch. I use it for quite a time now in production with 
prefork. I know there are issues with worker. So, I don't recommend 

In modperl_callback.c at line 202 you'll find these lines:

   /* XXX: would like to do this in modperl_hook_create_request()
    * but modperl_interp_select() is what figures out if
    * PerlInterpScope eq handler, in which case we do not register
    * a cleanup.  modperl_hook_create_request() is also currently always
    * run even if modperl isn't handling any part of the request
   modperl_config_req_cleanup_register(r, rcfg);

This is inside the modperl_callback_run_handlers() function which is the 
central point that runs all PerlXXXHandlers. That's why you need at 
least one PerlXXXHandler to activate the PerlCleanupHandler. In the 
threading branch the modperl_config_req_cleanup_register() call could 
have been moved to the create_request hook as mentioned in the comment.


Need professional mod_perl support?
Just hire me:

View raw message